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So  if  a  man's  wit  fce  wandering , 
let  him  study  the  mathematics 

-  Francis  Bacon 


1.  SECURITY  AND  RELIABILITY 


When  digital  computers  first  began  being  used  in  the  1950’s, 
people  just  programmed  their  computers  in  machine  or  assembly 
language  and  ran  their  programs .  With  the  introduction  of 
higher-order  languages,  however,  and  particularly  with  the 
development  of  large  and  very  large  software  systems,  such  as 
those  of  the  Apollo  project,  for  example,  a  whole  new  set  of 
questions  and  problems  arose  that  the  early  programmers  could 
never  have  imagined.  How  can  we  prevent  timing  conflicts? 

How  can  we  prevent  data  conflicts?  How  can  we  prove  programs 
correct?  What  is  the  relation  between  synchronous  and  asynch¬ 
ronous  processing?  How  can  we  make  an  operating  system  secure? 

All  of  these  questions  and  others  constitute  what  Parnas  [Par72a] 
has  termed  "the  so-called  ’software  engineering’  problem" 

(p.  330). 

One  of  the  most  interesting  instances  of  this  software-engineering 
problem  is  that  of  guaranteeing  system  security.  How  can  access 
to  the  various  components  of  a  system  be  restricted  specifically  to 
those  for  whom  it  is  intended?  Linden  [Lind76]  points  out  that 
there  are  many  similarities  between  the  requirements  of  security 
and  the  requirements  of  reliability ,  suggesting  that  "a  tech¬ 
nical  breakthrough  on  both  the  security  and  software  reliability 
problems  appears  to  be  as  feasible  as  a  breakthrough  on  the 
security  problem  alone"  (p.  410) .  Guaranteeing  security  re¬ 
quires  that  "operating  systems  must  be  structured  so  that  inter¬ 
actions  between  system  modules  are  more  clearly  defined  and  more 
closely  controlled"  (p.  411) ,  but  "this  same  control  over  the 
interaction  of  modules  is  also  needed  for  reliability." 
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Similarly,  "the  protection  mechanisms  needed  for  security  can 
also  be  used  to  enforce  software  modularity,"  and  "such  modularity 
would  improve  the  reliability  and  correctness  of  software." 

In  a  word,  "there  is  enough  overlap  between  the  requirements 
for  security  and  the  requirements  for  high  system  availability 
that  it  is  reasonable  to  attempt  to  solve  both  problems  at  the 
same  time."  (Availability  is  a  necessary  part  of  reliability, 
for  Linden.) 

In  this  report  we  will  argue  that  Linden  is  correct,  by  showing 
that  software  specified  according  to  the  Higher  Order  Software 
(HOS)  methodology  of  Hamilton  and  Zeldin  [Ham76a,b,77]  is  auto¬ 
matically  secure.  HOS  was  developed  as  a  means  of  guaranteeing 
system  reliability ,  without  any  concern  for  the  security  problem 
per  se.  Systems  specified  in  HOS  are  guaranteed  against  ever 
having  timing  or  data  conflicts  [Ham76b]  .  The  fact  that  they  also 
turn  out  to  be  secure  makes  HOS  exactly  the  kind  of  common  break¬ 
through  that  Linden  suggests  is  feasible. 

HOS  manages  to  solve  these  two  problems  by  showing  that  they 
need  not  arise  in  the  first  place.  If  software  is  specified 

according  to  the  principles  of  HOS,  then  there  is  no  need  to 

% 

ask  how  to  prevent  data  or  timing  conflicts,  because  there  simply 
will  be  no  such  thing.  Similarly,  ignoring  history  for  the 
moment,  if  software  had  always  been  specified  according  to  HOS, 
then  it  would  never  have  occurred  to  anyone  to  ask  how  to  make 
a  software  system  secure,  because  it  simply  would  have  been 
secure  already.  Demonstrating  this  latter  point  is  the  purpose 
of  our  present  paper. 

Many  people  have  recognized  that  the  key  to  solving  these  problems 
is  to  make  a  clean  separation  between  the  specification  of  a 
system  and  its  implementation,  and,  as  we  will  see,  HOS  is  a 
systems  theory  that  really  manages  to  do  this  successfully. 

We  will  see  that  trying  to  solve  the  reliability,  security, 
and  related  problems  entirely  in  terms  of  implementation  is  like 
trying  to  get  to  the  moon  on  a  skateboard.  Some  systems  theories 

2 
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enable  us  to  get  off  the  ground,  but  then  we  are  stranded  for¬ 
ever  in  the  orbit  of  implementation.  HOS  enables  us,  finally, 
t  to  achieve  escape  velocity,  break  free  of  this  orbit,  and  reach 

whatever  destination  we  have  decided  on. 
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2. 


THE  SECURITY  PROBLEM 


Linden  [Lind76]  presents  a  general  abstract  characterization  of 
system  security  in  terms  of  what  he  calls  a  protection  model. 

Such  a  model  "views  the  computer  as  a  set  of  active  entities 
called  subjects  and  a  set  of  passive  entities  called  objects. 

The  protection  model  defines  the  access  rights  of  each  subject 
to  each  object"  (p.  415). 

Linden  represents  a  protection' model  in  the  form  of  a  protection 
matrix,  such  as  the  one  in  Figure  1  [Lind76,  p.416].  The  rows  of 
a  protection  matrix  are  associated  with  the  subjects  of  the 
model  and  its  columns  are  associated  with  the  objects.  "For 
each  subject/object  pair,  the  corresponding  entry  in  the  matrix 
defines  the  set  of  access  rights  that  the  subject  has  to  the 
object."  For  the  protection  model  represented  by  the  protection 
matrix  in  Figure  1,  for  example,  we  see  that  subject  C  may 
read  or  execute  object  X,  because  both  "READ"  and  "EXECUTE"  appear 
in  the  matrix  slot  that  occurs  at  the  intersection  of  rov;  C 
and  column  X. 

Changes  to  the  protection  matrix  itself  are  also  controlled 
by  the  access  rights  represented  in  the  matrix;  "for  example, 
a  subject  with  'delete'  access  to  an  object  can  eliminate  that 
object  from  the  protection  matrix."  Subjects  can  be  allowed  to 
have  access  rights  to  each  other  by  having  subjects  appear 
also  as  objects  in  the  protection  matrix.  "For  example,  one 
subject  may  be  allowed  to  transfer  control  to  another  subject 
by  using  an  'enter'  access  right  to  the  other  subject." 

Linden  also  introduces  the  notion  of  a  protection  environment, 
which  includes  "everything  that  a  subject  might  cause  to  be  done 
on  its  behalf  by  another  subject,"  as  well  as  everything  the 
subject  is  allowed  to  do  directly.  "A  protection  domain  is 
a  more  restricted  .concept  and  includes  only  access  rights  to 
objects  that  are  accessible  by  the  subject."  The  rows  of  the 

PRECEDING  PAGE  BLANK 

5 

HPR  nRDFP  SOFTWARE.  INC.  •  843  MASSACHUSETTS  AVENUE  .  CAMBKIUUt,  MASBALHUbh. I  IS  U7139  •  1617)  661-8y00 


protection  matrix  represent  the  protection  domains  of  the  pro¬ 
tection  model. 

The  key  to  Linden's  approach  to  system  security  is  the  notion 
of  small  protection  domains.  Linden  uses  the  term  "small  pro¬ 
tection  domains"  as  "a  qualitative  description  of  a  certain 
class  of  protection  models.  The  word  ’small'  is  not  intended 
in  a  rigid  quantitative  sense"  (p.  416)  .  A  small  protection 
domain,  for  Linden,  is  the  minimal  protection  domain  that  will 
still  allow  its  subject  access  to  everything  it  has  to  access. 

A  protection  domain  may  be  very  large  in  a  quantitative  sense, 
but  it  is  a  "small"  protection  domain  if  it  could  not  be  decreased 
in  size  without  overly  restricting  the  access  rights  of  its 
subject.  Linden  calls  this  the  "principle  of  least  privilege." 

Since  "a  large  program  usually  needs  access  to  many  objects," 
it  follows  that 'protection  domains  can  be  kept  small  only  if 
a  large  program  executes  in  many  different  protection  domains 
and  constantly  switches  between  these  protection  domains  during 
its  execution."  Protection  domains  can  be  kept  small,  "if 
small  subunits  of  a  program  execute  in  their  own  protection 
domains,"  because  "a  small  subunit  of  a  program  typically  only 
needs  access  to  a  small  number  of  objects."  It  follows  that 
"the  flexibility,  ease,  and  efficiency  of  domain  switching 
is  the  primary  factor  in  determining  whether  protection  domains 
can  be  kept  small  and  closely  tailored  to  actual  needs." 

Linden  integrates  protection  domain  switching  with  the  calling 
of  a  procedure.  This  permits  each  procedure  to  have  its  own 
protection  domain,  even  though  a  domain  switch  might  not  be 
involved  in  every  procedure.  A  protected  procedure,  for  Linden, 
is  a  procedure  that  does  involve  a  domain  switch. 

If  a  procedure  is  a  protected  procedure,  then  it  will  have  a 
particular  protection  domain  associated  with  it.  "Thus  the 
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right  to  access  certain  objects  may  be  available  during  the 
execution  of  that  procedure — and  possibly  only  during  executions 
of  that  procedure."  Each  execution  of  a  protected  procedure 
will  possess  the  access  rights  of  the  procedure,  whatever  the 
calling  environment  may  be.  The  procedure  itself,  moreover, 

"can  have  a  state  which  is  preserved  between  calls  to  the  pro¬ 
cedure — and  that  state  is  independent  of  the  calling  environ¬ 
ments  . " 

Linden  points  out  that  a  protected  procedure  will  appear  both 
as  a  subject  and  as  an  object,  when  represented  in  a  protection 
matrix.  A  protected  procedure  is  an  object  because  there  may 
be  other  subjec-ts  that  have  the  right  to  call  it.  This  right 
is  represented  in  a  protection  matrix  by  the  appearance  of  a 
special  access  right,  such  as  the  "enter"  access  right  referred 
to  earlier.  A  protected  procedure  also  occurs  as  a  subject 
in  a  protection  matrix  because,  naturally,  "it  executes  in 
its  own  protection  domain." 

Switching  protection  domains  involves  calling  a  protected  pro¬ 
cedure.  The  simplest  case  of  domain  switching  is  the  one  in 
which  no  access  rights  are  passed  as  parameters  in  the  call. 

The  call  takes  place  and-execution  begins  in  the  protection 
domain  of  the  called  procedure,  as  long,  of  course,  as  the 
caller  has  the  right  to  call  this  procedure  in  the  first  place. 

Return  to  the  previous  protection  domain,  i.e.,  the  protection 
domain  of  the  caller,  is  triggered  by  a  return  instruction  in 
the  executing  called  procedure. 

This  situation  is  illustrated  in  the  protection  matrix  in 
Figure  2  [Lind76,  p.4D?  .  User  A  can  call  the  editor,  while 
executing  in  his  own  protection  domain.  He  can  also  read  or 
write  files  X  and  Y  either  from  his  own  domain  or  by  calling 
the  editor,  which  is  also  allowed  to  read  or  write  files  X 
and  Y.  The  user  can  use  the  dictionary,  however,  only  by 
calling  the  editor,  because  the  editor,  but  not  the  user  him¬ 
self,  is  allowed  to  read  the  dictionary. 

8 
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A  domain  switch  is  more  complex  if  it  involves  the  passing  of 
access  rights  to  objects  as  parameters  "and  if  the  protected 
procedure  is  to  be  reentrant."  This  kind  of  call  to  a  protected 
procedure  creates  a  new  protection  domain,  i.e.,  a  new  row  in 
the  protection  matrix.  "The  new  protection  domain  contains 
both  the  permanent  access  rights  of  the  protected  procedure," 
defined  by  a  template  domain  associated  with  the  procedure, 

"and  the  access  rights  that  are  passed  as  parameters  in  the 
call." 

This  kind  of  situation  is  illustrated  in  Figure  3  [Lind76,  p.41£>]  . 
Figure  3a  shows  the  User  A's  own  basic  domain  and  the  template 
domain  of  the  editor.  User  A  has  the  same  access  rights  as 
he  has  in  Figure  2,  but  the  editor  is  allowed  only  READ  access 
to  the  dictionary.  It  cannot  read  or  write  files  X  or  Y,  as 
it  can  in  Figure  2.  If  the  user  wants  to  use  the  editor  to 
read  file  X,  however,  he  can  pass  access  rights  for  file  X 
to  the  editor  in  the  process  of  calling  the  editor.  This  re¬ 
sults  in  the  creation  of  a  new  protection  domain,  labeled 
"INSTANCE  OF  EDITOR"  in  Figure  3b,  in  which  the  editor  does 
have  READ  access  to  file  X.  Linden  notes  that  "other  users 
may  be  editing  other  files  using  other  instances  of  the  same 
editor." 

K.  G.  Walter  [Walt75]  presents  what  is,  in  effect1,  a  for¬ 
malization  of  Linden's  account  of  security  in  the  form  of  a 
model  for  mandatory  security.  Walter  designs  his  model  to 
satisfy  the  "design  requirements ...  that  there  be  no  unauthorized 
disclosure  of  information  and  that,  otherwise,  unrestricted 
sharing  of  information  be  allowed."  The  model  is  based  on 
the  idea  of  restricting  access  to  information  by  giving  a 
specific  classification  for  each  piece  of  information  and  re¬ 
quiring  a  user  to  have  the  proper  clearance  in  order  to  access 
the  information. 

^Calling  Walter's  characterization  of  security  a  formalization 
of  Linden's  is  probably  historically  inaccurate,  since  Walter's 
account  appeared  a  year  and  a  half  earlier  than  Linden's. 

This  is  the  logical  relation  between  the  two  theories,  however, 
as  we  show  in  the  text. 

10 
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Figure  3b:  Protection  Matrix  during  Call  to  Editor 
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to  access  the  information. 


Formally,  Walter  describes  his  model  as  an  8-tuple 


Mq  =  (R,  A,  C,  6,  y,  <,  Cls ,  Clr) 


where 


R  is  a  set  of  repositories. 

A  is  a  set  of  agents. 

C  is  a  set  of  security  classes. 

0CA  x  R  is  the  "observe”  relation. 

(a  0  r  means  that  agent  a  can 
observe  the  information  stored  in 
repository  r.) 

y  C  A  x  R  is  the  "modify"  relation. 

(a  U  r  means  that  agent  a  can 
modify  the  information  stored  in 
respository  r.) 

4Cc  x  C  is  a  pre-ordering  of  the  set  of 
security  classes. 

CLS:  R  -*■  C  is  the  "classification"  function 

which  associates  a  security  class 
with  “each  repository.  (Informally 
Cls(r)  will  be  referred  to  as  the 
classification  of  repository  r.) 

CLR:  A  -*■  C  is  the  "clearance"  function  which 
associates  a  security  class  with 
each  agent.  (Here  again  Clr (a)  will 
be  referred  to  as  the  clearance  of 
agent  a.) 


Walter's  repositories  correspond  to  Linden's  objects,  while 
his  agents  correspond  to  Linden's  subjects.  The  observe 
and  modify  relations  correspond  to  two  general  kinds  of 
access  right  that  can  occur  in  a  protection  matrix.  The 
security  classes  in  MQ  correspond  to  Linden's  small  pro¬ 
tection  domains?  it  is  they  that  determine  which  repositories 
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(objects)  an  agent  (subject)  can  observe  or  modify  (access) . 

There  is  nothing  in  Walter’s  model  that  guarantees  a  null 
intersection  of  the  classes  of  agents  and  repositories,  so, 
as  with  Linden,  it  is  quite  possible  for  some  (or  all)  of  the 
entities  involved  to  be  both  subjects  and  objects. 

Walter  imposes  four  axioms  on  his  8-tuple  Mq  in  order  to  prove 
his  basic  security  theorem.  The  first  two  axioms  state 
explicitly  that  the  relation  £  provides  a  pre-ordering  of 
the  set  C  of  security  classes. 

Axiom  1:  For  all  c  e  C,  c  £  c. 

(<  is  reflexive.) 

Axiom  2:  For  all  c,  d,  eeC,  c^d  and  d  £  e 
implies  c  £  e.  (<  is  transitive.) 

"The  second  two  axioms  govern,  respectively,  the  acquisition 
and  dissemination  of  information." 

Axiom  3:  For  all  a  e  A  and  r  e  R,  a  0  r  implies 
Cls (r)  <  Clr (a) . 

That  is,  if  agent  a  can  observe  repository  r, 
then  the  clearance  of  a  must  be  greater  than 
or  equal  to  the  classification  of  r) . 

Axiom  4:  For  all  a  e  A  and  r  e  R,  a  u  r  implies  Clr (a)  < 

Cls (r) . 

That  is,  if  an  agent  a  can  modify  repository  r, 
then  the  clearance  of  a  is  less  than  or  equal 
to  the  classification  of  r.  Agent  a  can  modify 
only  those  repositories  with  equal  or  higher 
security  class.) 

Walter  says  that  "for  making  comparisons  it  is  sufficient  to 
assume  that  the  set  of  security  classes  is  pre-ordered , "  (p.  286) 
but  his  earlier  statement  that  "the  classification  system  has 
a  lattice  structure"  (p.  286)  ,  suggests  that  he  really  wants  a 
partial  ordering,  since  it  is  partial  orderings  that  induce 
lattice  structures.  Formally,  we  include  a  third  ordering 
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axiom  to  the  effect  that  something  cannot  be  both  higher  and 
lower  in  the  ordering  than  something  else,  as  follows: 

For  all  c,  d  e  C,  c  <  d  and  d  <  c 
implies  c  *  d. 

The  basic  security  theorem  states  that  "no  information 
can  ever  be  transferred  to  a  repository  in  which  it  can  be 
observed  by  an  agent  that  does  not  have  sufficient  clearance 
to  observe  the  source  repository."  Proving  this  theorem 
requires  the  introduction  of  a  "transfer"  relation  x  C  R  x  R, 
meaning  that  there  is  an  agent  that  can  transfer  information 
from  the  first  member  of  R  to  the  second  in  a  particular 
member  of  x.  Formally,  we  say  that  r  x  s  for  r  e  R,  s  e  R, 
if  and  only  if  there  is  an  a  e  A  such  that  a  ©  £  and  ays. 

The  basic  security  theorem  itself  requires  the  reflexive, 
transitive  closure  x*  of  x  and  the  notion  of  information 
transfer  path.  The  relation  r  x*  s  means  that  "there  is 
a  finite  sequence  of  repositories  {r^}  such  that  r  =  r^, 
s  =  rn+1,  and  x  r^+1  for  all  i,  1  _<  i  _<  n."  In  other 
words,  r  x*  s  if  and  only  if  information  can  eventually  be 
passed  from  r  to  s.  We -say  that  "there  is  an  information 
transfer  path  from  repository  r  to  repository  s,"  if  it  is, 
in  fact,  the  case  that  r  x*  s. 

Walter's  basic  security  theorem  can  be  stated  formally  in 
either  of  two  ways,  as  follows: 

Theorem:  For  all  r,  s  e  R,  if  r  x*  s,  then  Cls(r) 

<  Cls(s).  In  other  words,  if  there  is  an 
information  transfer  path  from  repository 
r  to  repository  s  then  Cls(r)  Cls(s). 

Corollary:  If  r  and  s  are  repositories  and  the  classifi¬ 
cation  of  r  is  not  less  than  or  equal  to 
the  classification  of  s,  then  there  is  no 
information  transfer  path  from  r  to  s. 
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What  this  theorem  says  is  that  if  information  flows  from  one 
repository  to  another,  then  the  latter  has  a  security  class 
that  is  the  same  as  or  higher  than  the  former;  in  other  words, 
information  can  flow  only  upwards.  Guaranteeing  that,  in  a  nut¬ 
shell,  is  what  the  security  problem  is  all  about. 


> 


> 


t 


I 


15 


HIGHER  ORDER  SOFTWARE,  INC.  •  843  MASSACHUSETTS  AVENUE  .  CAMBRIDGE,  MASSACHUSETTS  02139  •  (617)  661-8900 


3. 


SPECIFICATION,  IMPLEMENTATION ,  AND  LEVELS  OF  ABSTRACTION 


Walter  does  not  stop  with  Mq  ,  but  also  presents  two  other  models, 
,  which  is  outlined  in  Figure  4,  and  M2 ,  which  is  too  compli¬ 
cated  simply  to  exhibit  in  a  figure  without  further  explanation. 
Walter  describes  the  relationship  that  is  supposed  to  exist 
between  successive  models  in  the  sequence  MQ ,  ,  M2  in  terms 

of  a  "technique  of  structured  modeling"  (p.  288) ,  in  which 
successive  "levels  of  modeling"  are  used  to  arrive  at  the  full 
description  of  a  system.  He  also  uses  the  term  "Structured 
Specification"  (p.  285)  to  denote  the  approach  to  specification 
that  results  in  models  that  are  related  in  this  way.  Model 
"will  satisfy  the  security  requirements  in  Mp  plus  further  de¬ 
sign  requirements...  These  additional  restrictions  make  the 
design  more  implementation  specific"  (p.  288)  by  representing 
the  security  system  as  "a  file  system  structured  as  in  a  tree 
of  arbitrary  depth"  and  by  providing  "a  mechanism  for  inter¬ 
agent  communication  which  does  not  require  accessing  a  shared 
file"  (p.  290). 

M2  is  a  still  "more  specific  security  system  model”  (p.  290) 
involving  "mechanisms  which  will  be  used  as  discretionary 
controls  for  access  to  files."  Walter  says  that  the  defini¬ 
tion  of  Mq  "has  intuitive  appeal,  however,  the  way  to  apply 
Mq  to  a  complex  operating  system  is  far  from  obvious"  (p.  293) . 
As  for  M^,  "though  still  fairly  general,  this  model  is  ap¬ 
propriate  for  a  small  class  of  machines.  The  next  model,  M2, 
is  applicable  to  few  systems  besides  Multics,"  i.e.,  is  getting 
very  close  to  a  description  of  (part  of)  an  actual  operating 
system,  as  implemented..  "Eventually,  some  model  (probably 
an  or  M^)  will  closely  resemble  commands  in  the  Multics 
System. " 

A  general  framework  for  understanding  what  Walter  is  trying 
to  do  is  provided  by  the  SRI  systems  model  described  by 
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(F  fMjA/C#  pp  r  Op  /  ^  »Cls  ,Clr) 


WHERE: 

F 

M 

A 

C 

Pp  C  A  X  F 

Op  Q  A  x  F 
PM  C  A  X  M 

aM  Q.  A  x  M 

<  C  C  x  C 
6  C  F  x  F 


is  a  tree  of  files 

is  a  set  of  mailboxes 

is  a  set  of  agents 

is  a  set  of  security  classes 

is  the  "retrieve  information"  relation. 

(a  Pp  f  means  that  agent  a  can  retrieve  in¬ 
formation  from  file  f . ) 

is  the  "store  information”  relation. 

(a  Op  f  means  that  a  can  store  information  in  f.) 

is  the  "receive"  relation. 

(a  p^  m  means  that  agent  a  can  receive  infor¬ 
mation  through  mailbox  m. ) 

is  the  "send"  relation. 

(a  o„  m  means  that  a  can  send  information  to  m.) 

is  a  pre-ordering  of  the  set  of  security  class. 

is  the  "dominate"  relation  on  the  set  of  files. 
(It  defines  the  "tree"  structure  on  the  files.) 


Cls :  FUM  -*■  C 


is  the  "classification"  function  for  files 
and  mailboxes 


Clr :  A  -*■  C 


is  the  "clearance"  function  for  agents. 


AXIOMS  FOR  M1: 

Al.l:  For  all  c  e  C,  c  <  c 

(<  is  reflexive) . 

Al.2:  For  all  c,  d,  e  £  C,  c^d  and  d  <  e  implies  c  <  e 

H  is  transitive) . 

A1.3:  For  all  a  e  A  and  f  e  F,  a  pp  f  implies  Clr(f)  <  Clr(a). 

(An  agent  can  only  "retrieve"  information  from  a  file 
with  equal  or  lower  classification) . 


Figure  4:  Walter's  "Tree  Structured  Directory  Model  -  M^" 
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A1.4: 


For  all  a  e  A  and  m  e  M,  a  pk  m  implies  Cls (m)  =  Clr(a) . 

(An  agent  can  only  "receive"  information  through  a  mail¬ 
box  with  classification  equal  to  its  own  clearance) . 

A1.5:  For  all  a  e  A  and  f  e  F,  a  op  f  implies  Clr(a)  <  Cls(f). 

(An  agent  can  only  "store"  information  in  a  file  with 
equal  or  greater  classification) . 

A1.6:  For  all  a  e  A  and  m  e  M,  a  m  implies  Clr(a)  <  Cls(m) . 

(An  agent  can  only  "send"  information  through  a  mailbox 
with  equal  or  greater  classification) . 

Al.7:  For  all  f  e  F,  f  6  f  (6  is  reflexive) . 

A1.8:  For  all  f,  g  e  F,  f  .6  g  and  g  6  f  implies  f  =  g. 

(6  is  antisymmetric) . 

A1.9:  For  all  f,  g,  h  e  F,  f  6  g  and  g  6  h  implies  f  6  h. 

(6  is  transitive) . 

A1.10:  For  all  f,  g,  h  e  F,  g  6  f  and  h  6  f  implies  g  6  h 

or  h  6  f  (Sic) . 

(6  has  the  "tree"  property) . 

Al.ll:  For  all  a  e  A,  and  f,  g  e  F,  a  pp  g  and  f  6  g  implies 

a  pf  f,  (In  order  to  retrieve  information  from  a  file, 

an  agent  must  be  able  to  retrieve  from  (i.e.  search) 
every  file  which  dominates  it) . 

A1.12:  For  all  a  t  A,  and  f,  g  e  F,  a  op  g  and  f  6  g  and  f  ^  g 

implies  a  pp  f.  (In  order  to  store  into  a  file,  an 

agent  must  be  able  to  retrieve  from  or  search  every  file 
which  strictly  dominates  it.  This  specifically  allows 
an  agent  to  store  in  a  file  from  which  it  cannot  re¬ 
trieve;  i.e.,  write-up  is  permitted.) 

A1.13:  For  all  a  e  A,  and  f,  g  e  F,  a  op  f  and  f  6  g  implies 

a  op  g.  (Since  it  is  expected  that  attributes  of  a  file 

will  be  maintained  in  a  dominating  file  (directory) ,  if 
an  agent  can  store  into  a  directory  file  and  thus  change 
attributes  of  an  inferior  file,  then  the  agent  must  also 
be  able  to  store  into  (modify)  the  inferior  file) . 

A1.14:  For  all  f  e  F,  there  exists  an  a  e  A  such  that  a  cp  f . 

(There  are  no  files  which  cannot  be  stored  into  (modified) 
by  at  least  one  agent) . 


Figure  4:  Walter':  "Tree  Structured  Directory  Model  -  M, " 

(con ' t)  1 
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2 

Robinson  [Robi75] ,  [Robi77] .  Robinson  characterizes  a  sys¬ 
tem  description  in  terms  of  "a  sequence  of  ordered  pairs 
{ (PQ,  Mq) ,  (P^,  Mj) , . . .  (Pn,  Mn) } . . .  called  a  hierarchically 
structured  program"  (p.  272)  in  which  P^  is  a  set  of  abstract 
programs  that  run  on  the  abstract  machine  M^.  He  notes  that, 
in  general,  the  pairs  will  occur  in  a  tree  structure,  and  that 
he  assumes  a  linear  ordering  only  in  order  to  simplify  the 
argument . 

Each  program  runs  on  a  machine,  but  since  the 
collection  of  machines  forms  a  hierarchy,  the 
primitive  operations  of  a  machine  at  some  level 
are  realized  by  a  set  of  programs  running  on 
a  machine  at  the  next  lower  level  (one  program 
corresponding  to  each  operation  of  the  machine) 

(p.  272)  . 

"The  programs  abstract  from  the  implementation  details  of 
machines  on  which  they  run"  and  "the  only  information  avail¬ 
able  to  a  program  is  the  external  behavior  of  the  machine." 

The  general  idea  of  this  structuring  is  illustrated  in  Figure  5, 
in  which  "MQ  is  the  most  primitive  machine  and  can  be  viewed 
as  the  instruction  set  for  a  hardware  machine  or  as  a  higher- 
order  language"  and  in  which  "Pn  is  the  abstract  program  at 
the  highest  level,  running  on  machine  Mn»"  The  direction  of 
the  arrows  in  the  diagram  represent  the  flow  of  implementa¬ 
tion,  in  the  sense  that, "for  all  values  of  i(0  <  i  <  n),  the 
set  of  abstract  programs  P .  running  on  the  abstract  machine 
implements  the  abstract  machine  M^+^,"  while  itself  run¬ 
ning  on  abstract  machine  .  "The  system  as  a  whole  is 
equivalent  to  some  program  P  running  on  a  machine  M,  where 

M  =  M.  and  P  is  an  abstraction  of  P." 
u  n 

Each  of  the  abstract  machines  in  Robinson's  framework  "can 
be  described  as  a  module  of  Parnas...in  which  both  the  in¬ 
ternal  state  and  the  transformation  rules  are  characterized 

2 

The  model  description  in  [Robi75]  differs  somewhat  from  that 
of  [Robi77] .  We  will  quote  the  latter,  unless  otherwise 
noted . 
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Decreasing  Implementation 


by  running  on  this  machine 


by  running  on  this  machine 


by  running  on  this  machine. 


.  oroS 


by  running  on  this  machine. 


Figure  5 


SRI  Model  of  Program  P  to  Run  on  Machine  M 


-M0  =  M 
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as  functions  of  two  types  -  V-functions  (Value  functions)  and 
O-functions  (Operation  functions)."  Each  "program  running  on 
an  abstract  machine  can  be  expressed  as  a  sequence  of  calls 
to  the  functions  that  make  up  an  abstract  machine."  A  V-f unc¬ 
tion  is  one  that  "returns  a  value  when  called;  the  set  of 
possible  V-function  values  of  the  module  defines  the  state 
space  (or  abstract  data  structure)  of  the  module."  A  module's 
state  is  denoted  by  a  particular  set  of  values  for  each  V- 
function.  O-functions  describe  state  transformations  by  de¬ 
fining  new  values  for  V-functions.  "A  state  transformation 
occurs  when  an  O-function  is  called  and  is  described  as  an 
assertion  relating  new  values  of  V-functions  to  their  values 
before  the  call'."  Such  an  assertion  "is  a  predicate  con¬ 
taining  V-functions  for  which  the  predicate  is  true."  It 
"specifies  that,  as  a  result  of  a  call,  the  new  state  is  one 
of  some  set  of  possible  states;  therefore  the  specification 
may  be  incomplete."  The  effect  of  this  feature  is  that  it 
"postpones  binding  of  certain  decisions  until  the  abstract 
program  is  implemented  or  even  until  run-time."  An  example 
of  an  abstract  machine  characterized  as  a  Parnas  module 
specification  is  given  in  Figure  6  [Robi77,  p .273]  . 

Except  for  its  reversed  numbering  scheme,  it  seems  reasonably 
clear  that  the  SRI  framework  we  have  just  outlined  corresponds 
more  than  roughly,  in  intent,  to  Walter's  "technique  of 
structured  modeling"  or  "Structured  Specification."  Whereas 
Walter  denotes  his  most  abstract  "level  of  modelir.j"  by  the 
number  0,  with  increasing  numbers  as  we  get  closer  to  imple¬ 
mentation,  Robinson  uses  0  to  denote  his  least  abstract  "level 
of  abstraction,"  with  numbers  increasing  as  we  get  further 
away  from  that  level.  The  basic  idea  behind  the  separation 
of  levels,  however,  is  pretty  much  the  same  in  both  frame¬ 
works  . 
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integer  V-f unction:  LENGTH 

Comment:  Returns  the  number  of  occupied  positions  in  the 

register . 

Initial  value:  LENGTH  =  0 
Exceptions :  none 

Integer  V-f unction:  CHAR (integer  i) 

Comment:  Returns  the  value  of  the  ith  element  of  the 

register. 

Initial  value:  ViL(CHAR(i1)  =  undefined) 

Exceptions:  I_OUT_OF_BOUNDS :  i  <  0  V  i  >  LENGTH 

0- function:  INSERT (integer,  i,^_) 

Comment:  Inserts  the  value  j_  after  position  i,  moving 

subsequent  values  one  position  higher. 

Exceptions : 

I_OUT_OF_BOUNDS :  i  <  0  V  i  >  LENGTH 
J_0UT_0F_B0UNDS :  j  <  0  V  j  >  255 
TOO_LONG :  LENGTH  >_  1000 

Effects:  LENGTH  =  'LENGTH'  +  1 

Vk (CHAR (k)  =  if  k  <  i  then  'CHAR' (k) 
else  if  k  =  i  +  1  then  j. 
else  'CHAR'(k-l)) 

O- function:  DELETE  (integer  i^) 

Comment:  Deletes  the  ith  element  of  the  register, 

moving  the  subsequent  values  to  fill  in  the  gap. 

Exceptions:  I_0UT_0F_B0UNDS :  i  <  0  V  i  >  LENGTH 

Effects : 

LENGTH  =  'LENGTH'  -  1 
Vk (CHAR (k)  =  if  k  <  i  then  'CHAR' (k) 
else  'CHAR' (k  +  1) ) 

Figure  6 

Robinson's  Register  Module  Specification 
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Walter  describes  the  idea  behind  his  methodology  as  follows: 


In  many  ways.  Structured  Specification  is  similar 
to  Structured  Programming;  "levels  of  specification" 
are  analogous  to  the  "levels  of  abstraction"  dis¬ 
cussed  in  Structured  Programming.  However,  in  some 
sense,  these  concepts  are  orthogonal  to  each  other. 
Structured  Programming  is  a  technique  for  evolving 
an  orderly  description  of  how  a  particular  problem 
will  be  solved.  Typically,  it  is  a  matter  of  filling 
in  the  "nitty-gritty"  details  of  an  algorithm,  which 
is  well  understood. 

Conversely,  Structured  Specification  concentrates 
on  evolving  an  orderly  description  of  precisely 
what  problem  is  to  be  solved.  In  addition,  the 
various  levels  of  specification  provide  a  forum  for 
discussing  why  the  program  is  being  designed  in  a 
particular  way.  (p.  285)  . 


Differences  in  terminology  aside  (for  example,  Robinson's 
"levels  of  abstraction"  would  seem  to  be  intended  to  cor¬ 
respond  to  Walter's  "levels  of  specification,"  as  well,  per¬ 
haps,  as  to  the  "levels  of  abstraction"  of  structured  program¬ 
ming)  ,  the  aim  of  Robinson's  methodology  is  the  same. 


Robinson, like  Walter,  is  concerned  with  specification,  not 
with  implementation ,  except  as  an  ultimate  aim.  Systems  must 
eventually  be  implemented,  of  course,  but  this  is  not  the 
point.  He  describes  his  methodology  as  one  which  "formally 
represents  a  program  in  terms  of  levels  of  abstraction,  each 
level  of  which  can  be  described  by  a  self-contained  non¬ 
procedural  specification."  (p.  271).  The  point  is  that  a 
program  is  intended  to  be  characterized  in  terms  of  what  it 
is  supposed  to  do  (non-procedural) ,  rather  than  in  terms  of 
how  (procedural)  it  is  supposed  to  do  it,  exactly  as  Walter 
says. 
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Robinson's  characterization  of  a  level  of  abstraction  in 
terms  of  abstract  machines  is  not  a  problem,  because  this 
involves  only  a  choice  of  conceptualization  and  does  not 
necessarily  have  to  affect  the  formal  methodology  in  an  ad¬ 
verse  way.  A  problem  is  created  by  the  use  of  abstract  pro¬ 
grams  ,  however,  in  the  actual  characterization  of  the  ab¬ 
stract  machines.  A  program  is,  b^  definition ,  a  sequence 
of  instructions,  and  so  is  intrinsically  procedural.  Indeed, 
Robinson  characterizes  "a  program  running  on  an  abstract 
machine... as  a  sequence  of  calls  to  the  functions  that  make 
up  an  abstract  machine"  (p.  272),  as  we  have  seen.-  As  long 
as  a  systems  framework  uses  abstract  programs  to  characterize 
the  functions  of  his  primitive  machines,  we  are  automatically 
dealing  with  the  how  of  those  functions,  rather  than  the  what, 
i.e.,  with  their  implementation,  rather  than  their  specifi¬ 
cation. 

We  should  note  Robinson's  assertion  that  "the  Parnas  speci¬ 
fication  language  expresses  state  transformations  in  a  non¬ 
procedural  way...  A  Parnas  module  specification  is  a  self- 
contained  medium  for  defining  an  abstraction:  V-functions 
are  primitive,  and  O-functions  are  described  solely  in  terms 
of  V-functions  and  the  constructs  of  the  assertion  language." 
What  he  means,  presumably,  is  that,  since  the  O-functions 
can  be  reduced  to  ("described  solely  in  terms  of")  the  V- 
functions  and  since  the  V-functions  are  primitive ,  i.e. ,  not 
further  reducible,  there  is  nothing  more  that  he  has  to  do  to 
characterize  the  module.  Those  functions  (0-)  which  can 
be  reduced  have  been  reduced  and  those  functions  (V-)  which 
have  not  been  reduced  need  not  be  reduced,  because  they  cannot 
be  reduced.  That,  after  all,  is  the  meaning  of  "primitive." 
While  it  is  true  that  the  primitive  elements  of  a  system  (any 
kind  of  system)  cannot  (or  need  not)  be  further  reduced 
(decomposed,  described,  etc.)  in  terms  of  other  elements  of 
the  system,  however,  it  by  no  means  follows  that  there  is  no 
need  to  characterize  them  at  all. 
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Consider  a  simple  case  from  plane  Euclidean  geometry.  In  that 
geometry,  we  can  take  the  notions  of  point  and  line  as  primi¬ 
tives  and  notions  like  rectangle ,  triangle ,  and  vertex  as 
non-primitives  that  can  be  described  in  terms  of  the  primi¬ 
tives.  Thus  point  and  line  correspond  to  Robinson's  V-f unctions, 
since  he  says  these  are  primitive,  while  rectangle ,  triangle, 
and  vertex  correspond  to  his  O-functions,  since  he  says  these 
are  not  primitive,  but  "are  described  solely  in  terms  of  V- 
f unctions."  A  rectangle  or  a  triangle  can  be  described 
(roughly,  to  avoid  getting  too  technical  and  missing  the  main 
point)  as  a  particular  configuration  of  lines ,  and  a  vertex 
can  be  described  as  a  point  that  is  the  intersection  of  two 
lines .  Thus  the  non-primitives  are  described  in  terms  of  the 
primitives,  exactly  as  Robinson  wants. 

The  story  does  not  end  here,  however.  While  reduction  of  geo¬ 
metric  entities  ends  at  the  level  of  point  and  line  (and  per¬ 
haps  other  primitives,  which  we  are  ignoring  for  simplicity) , 
point  and  line  themselves  are  then  characterized  in  terms  of 
each  other,  i.e.,  in  terms  of  their  mutual  interaction,  by 
means  of  axioms.  Something  is^  a  point  or  a  line  if  and  only 
if  it  behaves  in  accord  with  the  axioms.  The  axioms  of  a 
geometry,  in  fact,  are  its  most  important  part,  because  every¬ 
thing  else  about  the  geometry  follows  from  them,  once  the 
appropriate  definitions  of  non-primitive  entities  in  terms 
of  primitive  ones  are  stated. 

What .this  means  in  Robinson's  case  is  that  it  is  not  enough 
simply  to  state  that  the  V- functions  are  primitive  and  leave 
it  at  that.  Looking  carefully  at  Figure  6,  we  see  that  the 
only  way  that  V-functions  are  characterized  within  the  module 
is  in  terms  of  informal  comments,  in  English,  that  tell  us 
what  the  functions  are  supposed  to  do.  The  formalism,  however, 
places  no  constraints  on  what  these  functions  can  do,  except  for 
giving  them  initial  values  and  (perhaps)  restricting  their 
domains.  Literally,  any  function  that  has  these  initial 
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values  and  these  domains  can  serve  as  the  LENGTH  and  CHAR 
functions  in  the  module.  Since  this  is  too  general  for  what 
Robinson  intends,  he  is  forced  to  narrow  down  the  candidate 
functions  for  LENGTH  and  CHAR  by  characterizing  them  outside 
of  the  module  in  terms  of  abstract  programs ,  which  do  spell 
out  formally  and,  by  definition,  algorithmically  the  func¬ 
tions  that  he  wants.  This  step,  however,  ipso  facto  removes 
us  from  the  realm  of  specification  and  places  us  in  that  of 
implementation.  In  the  process,  we  lose  "the  major  advantages 
of  Parnas  specifications."  namely,  "that  they  abstract  from 
the  algorithms  of  implementation  and  are  self-contained"  (p.272). 

We  see  that  Parnas'  modules  do  not  really  characterize  their 
functions  completely,  as  they  are  supposed  to.  One  of  the 
underlying  reasons  for  this  problem  is  that  Parnas  tries  to 
make  his  modules  do  too  much.  Parnas  confuses  the  need  to 
decompose  a  system  into  subsystems  with  the  need  to  char¬ 
acterize  in  precise  terms  the  kinds  of  objects  the  system 
deals  with,  proposing  that  both  needs  can  be  satisfied  with  his 
single  notion  of  module. 


In  many  places,  Parnas  talks  about  "dividing  the  system  into 
modules  "  [Par72b,  p.  1053]  and  "decomposing  a  system  into 
modules,"  so  it  is  clear  that  modules  are  intended  to  be  the 
kind  of  thing  into  which  systems  are  decomposed .  With  respect 
to  the  STACK  module  in  Figure  7,  however,  he  tells  us  that 
it  is  proposed  as  a  definition  of  a  kind  of  object: 


We  propose  that  the  definition  of  a  stack  shown  in 
Example  1  should  replace  the  usual  pictures  of  imple¬ 
mentations  {e.g.,  the  array  with  pointer  or  the  linked 
list  implementations) .  All  that  you  need  to  know  about 
a  stack  in  order  to  use  it  is  specified  there.  There 
are  countless  possible  implementations  (including  a  large 
number  of  sensible  ones) .  The  implementation  should  be 
free  to  vary  without  changing  the  using  programs.  If 
the  using  programs  assume  no  more  about  a  stack  than  is 
stated  above,  that  will  be  true.  (p.  332) 
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It  follows  from  these  facts  that  Parnas  is  decomposing  systems 
into  kinds  of  objects,  but  this  is  not  the  sort  of  result  he 
really  wants.  It  is  this  kind  of  inadequacy  that  leads  Robinson 
to  try  to  augment  the  Parnas  methodology  with  things  like 
abstract  programs. 
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Function  PUSH (a) 
possible  values:  none 
I  integer:  a 

effect:  call  ERR1  if  a  >  p2  V  a  <  0  V  'DEPTH1  =  pi 
else  [VAL  =  a;  DEPTH  =  ’DEPTH"  +  1;] 

Function  POP 

possible  values:  none 

parameters:  none 

effect:  call  ERR2  if  'DEPTH'  =  0 

the  sequence  "PUSH (a);  POP"  has  no  net  effect  if  no  error 
calls  occur. 

Function  VAL 

possible  values:  integer  initial;  value  undefined 
parameters :  none 

effect:  error  call  if  'DEPTH'  =  0 

Function  DEPTH 

possible  values:  integer;  initial  value  0 
parameters :  none 

effect:  none 

pi  and  p2  are  parameters,  pi  is  intended  to  represent  the 
maximum  depth  of  the  stack  and  p2  the  maximum  width  or 
maximum  size  for  each  item. 

Figure  7 

Parnas'  Stack  Module 
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4.  HOS  AS  A  GENERAL  SYSTEMS  THEORY 

Like  Linden  and  Walter,  KOS  recognizes  that  there  are  essentially 
two  modes  of  existence  in  the  world,  that  of  being  and  that  of 
doing ,  and  that  everything  generally  manifests  both  modes  at 
once.  A  given  thing  can  either  be  or  do  and,  in  general,  will 
both  be  and  do  at  the  same  time.  This  dichotomy  reflects  the 
related  bifurcation  between  being  and  becoming .  If  there  is 
something  that  is  doing ,  then  there  is  something  (perhaps  the 
same  thing)  that  is  being  done  to,  and  this  latter  thing  is 
therefore  becoming .  Again,  in  general,  anything  that  is  doing 
is  also  being  done  to  and  so  is  itself  becoming ,  as  well  as 
being . 

This  enables  us  to  understand  the  important  relationship  be¬ 
tween  constancy  and  change.  If  we  remove  the  front  element 
from  a  queue,  for  example,  we  still  have  the  same  queue,  with 
one  element  removed,  but  we  also  have  a  different  queue,  i.e., 
the  one  that  differs  from  the  original  one  in  exactly  that 
element.  The  queue  can  still  be  the  same  queue,  even  though 
it  has  become  a  different  queue,  and  we  are  free  to  choose 
whichever  of  these  aspects  of  the  situation  fits  our  needs 
for  any  particular  problem.  We  can  also  say  the  queue  has 
changed  its  state,  stipulating  that  the  queue  itself  has  not 
changed,  but  then  it  is  the  states  that  are  being  or  becoming, 
so  the  same  dichotomy  emerges  again  on  a  higher  level  of  ab¬ 
straction. 

Linden  expresses  the  distinction  between  being  and  doing  in 
terms  of  his  distinction  between  objects  and  subjects ,  as 
we  have  seen.  Objects  are  things  that  are  done  to,  i.e., 
they  simply  are ,  rather  than  do.  Subjects,  in  contrast, 
are  things  which  do,  and  the  objects  are  precisely  the  things 
they  do  to.  Walter  expresses  this  dichotomy  in  terms  of  his 
distinction  between  repositories  and  agents ,  as  we  have  also 
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seen.  Agents  are  things  which  do,  and  repositories  are  things 
which  are  and  which  therefore  are  done  to  by  the  agents.  As 
we  have  discussed,  anything,  in  general,  will  both  be  and  do, 
so  anything  is  both  an  agent  and  a  repository  and  both  a  sub¬ 
ject  and  an  object,  as  Linden,  and  presumably  Walter,  would 
agree. 

While  both  Linden  and  Walter  thus  recognize  this  fundamental 
dichotomy  in  any  system,  there  are  serious  defects  in  their 
formulations  of  this  dichotomy.  The  problem  with  Linden's 
formulation  is  that  it  is  not  formal.  All  he  tells  us  is  that 
"a  protection  model  views  the  computer  as  a  set  of  active 
entities  called  subjects  and  a  set  of  passive  entities  called 
objects"  (p.  415) ,  with  no  formal  characterization  of  what 
these  sub ject/object  things  or  their  properties  are  supposed 
to  be.  Such  an  omission  is  perfectly  justifiable  in  the  con¬ 
text  of  the  general  survey  sort  of  article  in  which  it  occurs, 
but  it  must  be  corrected  in  a  complete  systems  theory. 

Walter's  formulation  is  quite  formal,  but  it  falters  in  a 
different  respect.  A  fully  general  systems  theory  should  be 
capable  of  expression  at  the  highest  possible  level  of 
generality.  Like  Linden's  account  it  should  state  things 
solely  in  terms  of  subjects  and  objects,  i.e.,  things  that 
do  and  things  that  are ,  at  this  highest  level  of  generality, 
while  permitting  subcategorizations  of  these  basic  categories, 
e.g.,  procedure,  protection  domains,  etc.,  at  lower  levels 
of  generality:  Walter's  problem  is  that  he  conflates  levels 

by  including  something  not  at  all  on  a  par  with  agents  and 
repositories  with  respect  to  generality ,  i.e.,  security 

classes,  on  the  highest  level  of  generality  of  his  systems 
theory .  Again,  within  a  sufficiently  limited  domain  of  in¬ 
terest,  Walter's  decision  to  lump  the  highly  specific  notion 
of  security  classes  in  with  the  completely  general  notions  of 
agent  and  repository  is  excusable,  but  outside  of  such  a  domain, 
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it  will  place  unnecessary  restrictions  on  any  system  specified 
in  accordance  with  the  theory.  A  general  systems  theory 
should  allow  the  introduction  of  lower-level  notions  like 
security  classes,  if  they  are  needed,  but  it  should  not  require 
them  on  its  most  general  level,  where  only  agents  and  re¬ 
positories  should  reside. 

HOS  expresses  the  distinction  between  being  and  doing  in 
terms  of  the  familiar  notions  of  data  and  function ,  and  it 
does  this  in  a  completely  formal  way.  Anything  that  can  be 
can  be  represented  as  a  member  of  a  data  type ,  and- anything 
that  can  do  can  be  represented  as  a  function'*.  As  we  would 
expect  from  a  correct  formulation,  anything  that  can  be,  i.e., 
a  datum,  can  also  do,  by  serving  as  input  to  a  function,  and 
anything  that  can  do,  i.e.,  a  function,  can  also  be,  since 
functions  themselves  make  up  a  data  type. 

For  example,  if  datum  x  is  mapped  by  functions  f^,  f 2 /  ^3/ 
f4,  f5  onto  data  y^,  y2 ,  y3,  y4,  y5,  respectively,  then  x 
itself  can  be  viewed  as  a  function  that  maps  the  data  f ^ ,  f2, 
f 3 ,  f4,  f5  onto  y^,  y2,  y3,  y4 ,  y5»  Functions  themselves 
can  be  data,  in  other  words,  and  data  can  be  functions, de¬ 
pending  on  the  requirements  of  the  particular  problem  we  are 
working  on.  If  FXY  is  the  subset  of  data  type  FUNCTION  whose 
members  map  data  type  X  into  data  type  Y,  then  X  is  the  sub¬ 
set  of  FUNCTION  that  maps  FXY  into  Y.  Both  interpretations 
are  correct,  in  general,  and  which  one  we  choose  depends  on 
what  we  need  for  a  specific  problem. 


In  our  formulation,  however,  unlike  Linden's,  this  revers- 
ability  follows  naturally  from  the  nature  of  data  and  functions. 

We  do  not  really  have  to  say  explicitly  that  subjects  can  also 
be  objects  and  vice  versa,  because  that  fact  follows  automati¬ 
cally  from  our  identification  of  subjects  with  functions  and 
objects  with  data. _ 

^[Ham76aj  uses  the  term  "function"  in  a  more  highly  restricted  sense  and  the 
term  "operation”  in  the  sense  of  our  "function."  For  our  present  purposes, 
the  distinction  is  unimportant,  and  we  will  use  the  two  terms  interchangeably. 
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Again  in  accordance  with  the  fundamental  dichotomy,  although 
data  and  functions  are  distinct  components  of  systems,  they 
are  at  the  same  time  inseparable  from  each  other, because 
each  is  characterized  formally  in  terms  of  the  other.  A 
function  consists  of  an  input  data  type,  called  its  domain, 
an  output  data  type,  called  its  range ,  and  a  correspondence, 
called  its  mapping ,  between  the  members  of  its  domain  and  those  of 
its  range;  a  function  can  be  characterized,  therefore,  as  an 
ordered  triple  (Domain,  Range,  Mapping) ,  where  the  components 
are  as  we  have  just  stated.  A  data  type  consists  of  a  set 
of  objects,  called  its  members ,  and  a  set  of  functions,  called 
its  primitive  operations ,  which  are  specified  by  giving  their 
domains  and  ranges,  at  least  one  of  which  for  each  primitive 
operation  must  include  the  data  type's  own  set  of  members,  and 
a  description  of  the  way  their  mappings  interact  with  one 
another  and,  perhaps,  with  those  of  other  functions;  a  data 
type  can  thus  also  be  characterized  as  an  ordered  triple,  this 
time  (Set,  DR,  Axioms) ,  where  Set  is  the  set  of  its  members, 

DR  is  a  statement  of  the  domains  and  ranges  of  its  primitive 
operations,  and  Axioms  is  a  description  of  the  interactive 
behavior  of  the  mappings  of  the  primitive  operations. 

An  example  of  an  HOS  data-type  specification,  namely, type 
STACK,  is  given  in  Figure  8  ,  written  in  the  HOS  specification 
language  AXES  [Ham76a].  It  is  not  difficult  to  see  that  this 
specification  avoids  all  of  the  problems  that  we  discussed 
in  connection  with  Parnas '  stack  module  in  Figure  7 .  The 
specification  in  Figure  8  has  absolutely  nothing  to  do,  by 
itself,  with  system  decomposition.  It  is  a  definition  of 
a  kind  of  object,  plain  and  simple,  and  thus  serves  exactly 
the  kind  of  purpose  it  is  suited  to  serve,  rather  than  trying 
to  overextend  itself,  as  Parnas'  module  does.  Furthermore, 
it  is  entirely  self-contained,  because  the  primitive  operations 
are  characterized  in  terms  of  each  other,  rather  than  being 
left  dangling  in  the  "module"  to  be  rescued  by  abstract 
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DATA  TYPE:  STACK; 

PRIMITIVE  OPERATIONS: 

stack^  =  Push(stack2,  integer^); 

stack^  =  Pop(stack2); 

integer^  =  Top(stack^); 

AXIOMS : 

WHERE  Newstack  IS  A  CONSTANT  STACK; 
WHERE  s  IS  A  STACK; 

WHERE  i  IS  AN  INTEGER: 

Top (Newstack)  =  REJECT; 

Top (Push (s, i) )  =  i; 

Pop (Newstack)  =  REJECT; 

Pop (Push ( s, i) )  =  s; 

END  STACK; 


Figure  8 


HOS/AXES  Data  Type  Stack 
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programs.  Finally,  it  is  absolutely  implementation-free, 
because  any  implementation,  whether  made  up  of  vacuum  tubes, 
transistors,  integrated  circuits,  magnetic  bubbles,  or  ice¬ 
cream  cones,  will  be  a  satisfactory  implementation,  as  long 
as  primitive  operations  can  be  defined  in  the  implementation 
that  behave  in  accordance  with  the  axioms. 

An  interesting  thing  happens  when  we  try  to  specify  Walter's 
Mq  in  terms  of  HOS  data  types.  The  first  thing  we  notice 
about  Mq  is  that  repositories  are  more  basic  than  agents. 

An  agent,  in  Walter's  terms,  is  anything  that  can  observe  or 
modify  a  repository,  while  a  repository  is  anything  at  all 
that  can  be  partially  ordered.  Walter  says  that  "associated 
with  each  repository  is  a  security  class  which  measures  the 
relative  sensitivity  of  the  information  stored  within  it." 
Since  the  only  real  function  of  the  security  class  is  to 
measure  "relative  sensitivity,"  it  follows  that  their  func¬ 
tion  could  be  accomplished  just  as  well  by  partially  order¬ 
ing  the  repositories  themselves.  This  enables  us  first  to 
characterize  the  class  of  repositories  as  a  data  type  inde¬ 
pendently  of  the  class  of  agents  and  then  to  characterize 
the  class  of  agents  as  a  data  type  in  terms  of  the  data 
type  REPOSITORY.  It  also  enables  us  to  eliminate  the  class 
of  security  classes  altogether  from  our  model  by  imposing 
our  partial  ordering  directly  on  the  data  type  REPOSITORY 
and  assigning  each  agent  a  maximal  repository  it  can  observe 
and  a  minimal  repository  it  can  modify.  This  confirms  our 
earlier  observation  that  Walter  is  conflating  levels  of 
generality  in  his  model.  Security  classes  can  be  introduced 
as  a  data  type  at  a  lower  level  of  generality,  if  they  are 
really  needed  for  a  particular  problem,  or  if  they  are  simply 
desired  for  reasons  of  convenience  or  elegance,  but  they  have 
no  place  on  the  highest  level  of  generality  of  a  general 
systems  theory. 
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Figure  9  gives  the  HOS  specification  of  data  type  REPOSITORY, 

written,  as  usual,  in  AXES..  As  just  noted,  the  only  primitive 

operation  we  need  in  this  data  type  specification  is  the 

partial  ordering  Atmost,  whose  axioms  are  available  with  AXES 

4 

and  thus  do  not  need  to  be  stated  explicitly. 


DATA  TYPE:  REPOSITORY; 

PRIMITIVE  OPERATIONS: 

boolean  =  Atmost (repository^ ,  repository^) 
AXIOMS: 

END  REPOSITORY; 

Figure  9 

HOS  specification  of  data  type  REPOSITORY 


Note  that  whereas  Walter  treats  his  partial  ordering  as  a 
general  relation,  i.e.,  as  a  general  subset  of  C  x  C,  or  equi¬ 
valently,  a  general  set  of  ordered  pairs  (C^,^),  we  treat 
it  as  a  function,  i.e. ,  a  subset  of  REPOSITORY  x  REPOSITORY 
x  BOOLEAN  in  which  the  first  two  components  of  each 
(R^ . R-  ,b)  uniquely  determine  the  third.  The  possibility 
of  treating  any  relation  as  a  function  that  maps  into  BOOLEAN 
is  a  general  property  of  relations  which  HOS  takes  full  ad¬ 
vantage  of.  It  enables  us  to  integrate  the  treatment  of  re¬ 
lations  that  might  not  normally  be  viewed  as  functions  into 
the  general  functional-decomposition  framework  of  HOS  and  thus 
to  see  how  such  "non-functional"  relations  fit  into  the  system 
as  a  whole  of  which  they  are  a  part. 

4 

Equality  is  also  needed,  but  this  is  provided  in  AXES  itself 
for  every  data  type.  Atmost  is  not  a  universal  operation, 
as  Equality  is,  but  is  universally  available ,  in  that  we  can  in¬ 
clude  it  in  any  data  type  specification  with  whose  axioms  its 
own  axioms  are  consistent.  The  axioms  of  Atmost  are  stated  once 
and  for  all  in  AXES  and  thus  need  not  be  restated  every  time 
the  operation  is  included  among  those  of  a  particular  data  type. 
Once  Atmost  is  included  among  the  primitive  operations  of  a 
particular  data  type,  its  axioms  are  automatically  those  that 
are  stated  for  it  in  the  theory.  See  [Cus77a]  for  discussion 
of  these  ideas. 
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Figure  10  gives  the  AXES  specification  for  data  type  AGENT^.  As  noted  earlier, 
there  is  one  primitive  operation,  Observeclearance ,  that  assigns  to  each  agent 
a  maximal  repository  it  can  observe  and  a  second  primitive  operation,  Modify- 
clearance,  that  assigns  to  each  agent  a  minimal  repository  it  can  modify. 

The  remaining  two  operations.  Observes  and  Modifies,  correspond  to  Walter's 
0  ("observe")  and  p  ("modify")  relations,  respectively,  in  the  way  discussed 
in  the  preceding  paragraph. 

DATA  TYPE:  AGENT; 

PRIMITIVE  OPERATIONS: 

repository  =  Observeclearance (agent) ; 
repository  =  Modifyclearance (agent) ; 
boolean  =  Observes (agent, repos itory) ; 
boolean  =  Modifies (agent .repository) ; 

AXIOMS: 

WHERE  a  IS  AN  AGENT 
WHERE  r  IS  A  REPOSITORY 

(Observes (a, r)  D  Atmost(r,Observeclearance(a))  =  True; 

(Modifies (a, r)  D  Atmost (Modifyclearance (a) ,r) )  =  True; 

Atmost (Observeclearance (a) ,  Modifyclearance (a) )  =  True; 

END  AGENT; 

Figure  10.  HOS  Specification  of  Data  Type  AGENT 

The  three  axioms  of  data  type  AGENT  together  provide  the  effect  of  Walter's 
Axioms  3  and  4,  without  the  use  of  "security  classes."  The  first  axiom  says 
that  if  an  agent  can  observe  a  repository,  then  that  repository  must  be  lower 
(but  not  necessarily  strictly  lower)  in  the  partial  ordering  of  repositories 
than  the  maximal  repository  the  agent  can  observe.  The  axiom  functions,  in 
other  words,  as  a  mutual  definition  of  "can  observe"  and  "maximal  observable 
repository"  in  terms  of  each  other  and  the  partial  ordering,  in  the  usual  man¬ 
ner  of  HOS  data-type  axioms.  The  second  axiom  says  that  if  an  agent  can 
modify  a  repository,  then  that  repository  must  be  higher  (though  perhaps  not 
strictly  higher)  in  the  partial  ordering  of  repositories  than  the  minimal  re¬ 
pository  that  the  agent  can  modify.  This  functions,  again,  as  a  mutual  defini¬ 
tion  of  "can  modify"  and  "minimal  modifiable  repository"  in  terms  of  each 
other  and  the  partial  ordering. 


Given  the  first  two  axioms,  the  third  axiom  provides  all  of  the  effect  of 
Walter's  "security  classes"  by  guaranteeing  that  the  maximal  observable 

^The  symbol  "  T?"  is  a  traditional  infix  symbol  for  material  implication 
in  formal  logic  and  is  used  here  in  place  of  the  AXES  prefix  operation 
symbol  "Entails"  [Ham76a] .  It  seems  reasonable  to  use  such  traditional 
infix  symbols  as  abbreviations  for  AXES  prefix  symbols,  whenever  this  is 
convenient,  and  this  convention  is  adopted  explicitly  in  [Han76a]  and  [Cus77a]. 
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repository  is  always  lower  in  the  partial  ordering  than  the  minimal 
modifiable  repository.  This  means  that,  for  a  given  agent,  the 
lattice  of  repositories  can  be  divided  into  an  "upper  half"  and  a 
"lower  half,."  such'  that  the  agent  can  observe  only  repositories  in 
the  lower  half  and  modify  only  repositories  in  the  upper  half. 

This,  however,  is  really  the  only  purpose  that  security  classes 
serve  in  Mg,  so  we  really  can  dispense  with  them  entirely,  as  we 
have  done . 

In  Walter's  terminology,  we  have  reduced  his  8-tuple 
(R,  A,  C,  6,  u,  <,  Cls ,  Clr) 

to  a  7-tuple 

(REPOSITORY,  Atmost,  AGENT,  Observes,  Modifies, 

Observeclearance,  Modifyclearance) 

by  showing  that  one  of  his  data  types  is  superfluous  and  that 
his  primitive  operations  that  map  into  that  type  can  be  re¬ 
placed  by  different  primitive  operations  which  have  the  same 
effect  but  which  have  only  the  two  remaining  data  types  as 
domains  and  ranges.  Whereas  Walter's  8-tuple  requires  two 
special  axioms,  besides  those  for  the  partial  ordering,  which 
are  intrinsic  to  AXES,  but  which  Walter  has  to  state,  making 
a  real  total  of  five  axioms  for  him,  our  7-tuple  requires 
only  three  explicitly  stated  axioms,  as  shown  in  Figure  5. 

It  should  be  noted  that  if  we  had  tried  to  specify  explicitly 
all  three  data  types  that  Walter  proposes,  we  would  immediately 
have  run  into  problems.  Walter  names  his  data  types  and  de¬ 
scribes  how  his  operations  (functions/relations)  are  supposed 
to  work,  but  he  does  not  explicitly  specify  either  the  opera¬ 
tions  or  the  types.  His  Axioms  3  and  4,  for  example,  really 
express  relationships  between  types,  rather  than  defining 
characteristics  of  the  individual  types  themselves.  From 
the  HOS  point  of  view,  this  amounts  to  putting  the  , cart  be¬ 
fore  the  horse,  stating  a  relationship  between  two  things 
before  we  have  any  idea  at  all  what  it  is  that  is  being  related. 
From  Walter's  point  of  view,  of  course,  this  is  perfectly  legi¬ 
timate,  because,  presumably,  he  views  the  situation  as  beir.c 
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analogous  to  that  of  points  and  lines  in  plane  geometry,  which 
also  are  usually  characterized  not  independently  as  data  types, 
but  in  terms  of  each  other.  The  advantage  of  our  point  of 
view  is  its  complete  generality.  Identifying  being  things 
and  doing  things  with  data  (types)  and  functions,  respectively, 
enables  us  to  specify  any  system  at  all  in  a  principled  way, 
without  introducing  any  further  kinds  of  entities.  Walter's 
formulation  of  this  distinction  in  terms  of  a  mutual  defini¬ 
tion  of  repositories  and  agents,  in  contrast,  still  requires 
him  to  use  functions  (and  relations,  for  that  matter)  to  de¬ 
fine  his  repositories  and  agents.  In  our  framework,  reposi¬ 
tories  and  agents  are  data  and  functions,  respectively,  and 
that  is  the  end  of  that. 

We  could  have  defined  a  type  "SECURITY  CLASS"  in  terms  of  the 
partial  ordering,  for  example,  but  then  we  would  have  been 
unable  to  write  axioms  on  the  data  types  AGENT  and  REPOSITORY 
for  the  "primitive  operations"  CLS  and  CLR  that  map  these 
types  into  that  type,  without  introducing  a  host  of  other 
"primitive  operations."  Similarly,  there  would  have  been 
no  non-arbitrary  way  to  decide  whether  6  and  u,  which  take 
both  agents  and  repositories  as  input,  should  be  "primitive 
operations"  on  AGENT  or  on  REPOSITORY.  By  recognizing  that 
the  only  function  of  "SECURITY  CLASS"  in  is  to  provide 
an  appropriate  partial  ordering  for  REPOSITORY,  we  can  see 
that  REPOSITORY  is  a  more  basic  data  type  than  AGENT  and 
define  the  partial  ordering  directly  on  REPOSITORY,  as 
we  did.  In  other  words,  REPOSITORY  is  "SECURITY  CLASS”  at 
the  level  of  ^generality  at  which  MQ  is  defined.  Whether 
we  call  that  single  type  "REPOSITORY"  or  "SECURITY  CLASS" 
is,  of  course,  entirely  a  matter  of  choice. 

The  other  important  function  that  Parnas  tries  to  make  his 
modules  serve,  i.e. ,  system  decomposition,  is  specified  in 
HOS  in  terms  of  decomposition  trees,  also  called  control 
maps .  Given  a  system  that  involves  certain  data  types,  the 
function  the  system  performs  can  be  decomposed  into  a  tree 
structure  whose  nodes  are  functions  and  whose  terminal  nodes, 
in  particular,  are  primitive  operations  of  the  data  types, 
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where  the  collective  effect  of  the  functions  at  the  terminal 
nodes  is  the  same  as  that  of  the  system  as  a  whole.  Such 
tree  structures  ate  not  intended  to  provide  definitions  of 
kinds  of  objects,  as  Parnas'  modules  are,  but  represent  system 
decompositions  into  subsystems,  plain  and  simple.  An  example 

a  •  t_ 

of  such  a  decomposition  tree,  for  the  function  y  =  is 

shown  in  Figure  11.  The  domain  and  range  of  the  decomposed 
function  can  be  determined  by  the  typed  variables  that  re¬ 
present  inputs  and  outputs  and  by  the  primitive  operations  that 
appear  at  the  terminal  nodes.  The  tree  itself  is  precisely 
what  gives  the  mapping  of  the  decomposed  function,  by  showing 
how  that  mapping  gets  accomplished  in  terms  of  the  collective 
behavior  of  the  independently  characterized  primitive  operations. 

The  key  to  the  usefulness  of  these  decomposition  trees  lies 
in  the  six  HOS  axioms,  listed  in  Figure  12.  It  is  these  axioms, 
in  fact,  and  their  consequences ,  of  course,  that  make  HOS  HOS. 
While  HOS  can  specify  any  system  that  can  be  specified,  the 
specification  must  be  in  accordance  with  these  axioms  or  the 
system  may  be  incomplete  or  unreliable.  Any  software  system, 
in  particular,  that  is  specified  in  accordance  with  these  axioms 
is  automatically  guaranteed  to  be  reliable,  in  the  sense  that 
no  data  or  timing  conflicts  can  ever  occur  [Ham76b] .  Formally, 
the  axioms  tell  us  that  a  well-formed  HOS  tree  is  always  equiva¬ 
lent  to  a  tree  in  which  every  node  is  occupied  by  one  of  the 
three  primitive  control  structures,  shown  in  Figure  13.  Abstract 
control  structures,  defined  in  terms  of  the  primitives  may 
also  appear  in  well-formed  trees,  and,  conversely,  any  control 
structure,  i.e.,  configuration  of  parent  and  offspring  nodes, 
can  appear  in  a  well-formed  tree  as  long  as  it  can  itself  be 
decomposed  into  the  primitives. 

Such  an  HOS  tree  can  be  interpreted  either  as  decomposing  a 
function  into  primitive  operations  or  as  building  up  a  func¬ 
tion  out  of  primitive  operations.  Which  interpretation  we 


4] 
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y  =  f(a,b,c,d) 


Figure  11 

HOS  Tree  for  Function  y  = 


a+b 

c-d 
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DEFINITION:  Invocation  provides  for  the  ability  to  perform  a  function. 

AXIOM  I,-  A  given  module  controls  the  invocation  of  the  set  of 
functions  on  its  immediate,  and  only  its  immediate 
V  lower  level. 

DEFINITION:  Responsibi 1 ity  provides  for  the  ability  of  a  module  to 
produce  correct  output  values. 

•  AXIOM  2:  A  given  module  controls  the  responsibility  for  elements 

of  its  own  and  only  its  own  output  space. 

DEFINITION:  An  output  access  right  provides  for  the  ability  to  locate  a 
variable ,  and  once  it  is  located,  the  ability  to  give  a  value  to 

*  the  located  variable. 

AXIOM  3:  A  given  module  controls  the  output  access  rights  to  each 
set  of  variables  whose  values  define  the  elements  of  the 
output  space  for  each  immediate,  and  only  each  immediate 
lower-level  function. 


DEFINITION:  An  input  access  right  provides  for  the  ability  to  locate 
a  variable,  and  once  it  is  located,  the  ability  to  reference  the 
value  of  that  variable. 

AXIOM  4:  A  given  module  controls  the  input  access  rights  to  each 
set  of  variables  whose  values  define  the  elements  of  the 
input  space  for  each  immediate,  and  only  each  immediate 
lower- level  function. 

DEFINITION:  Rejection  provides  for  the  ability  to  recognize  an  improper 
input  element  in  that,  if  a  given  input  element  is  not  acceptable , 
null  output  is  produced. 

AXIOM  5:  A  given  module  controls  the  rejection  of  invalid  elements 
of  its  own,  and  only  its  own,  input  set. 

DEFINITION:  Ordering  provides  for  the  ability  to  establish  a  relation 
in  a  set  of  functions  so  that  any  two  function  elements  are  corn- 
par  able  in  that  one  of  the  said  elements  precedes  the  other  said 
element . 

AXIOM  6:  A  given  module  controls  the  ordering  of  each  tree  for 
its  immediate,  and  only  its  immediate,  lower  level. 


Figure  12 
The  Axioms  of  HOS 
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y  =  f(x) 


SET  PARTITION 


Figure  13 

The  Three  Primitive  Control  Structures  of  HOS 
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choose  for  a  particular  tree  depends,  as  usual,  on  the  use  we 
want  to  make  of  it.  Under  either  interpretation  of  such  a 
tree,  however,  what  we  end  up  with  is  a  specification  of  the 
function  at  its  root  node  that  is  genuinely  non-procedural, 
i.e.,  non-algor ithmic,  and  entirely  free  of  implementation 
considerations.  The  tree  provides  a  complete  and  explicit 
account  of  what  functional  mapping  the  function  performs 
and  how  that  mapping  is  collectively  carried  out  on  the  types 
involved  by  their  primitive  operations.  Everything  is  clearly 
spelled  out  in  terms  of  the  hierarchical  organization  of 
functional  mappings,  and  this  — no  more,  no  less —  is  exactly 
what  we  require  of  an  adequate  specification  methodology. 

The  need  for  abstract  programs ,  i.e.,  (procedural)  sequences 
of  abstract  calls  to  the  primitive  operations  of  abstract 
machines ,  is  entirely  eliminated.  It  follows  that  replacing 
each  of  Robinson's  P^'s  with  an  HOS  tree  will  make  the  pro¬ 
blems  we  found  in  connection  with  his  "abstract  programs" 
disappear. 

It  is  worth  noting,  at  this  point,  that  HOS  does  not  distin¬ 
guish  at  all  between  O-functions  and  V-functions,  because, 
however  important  this  distinction  may  be  in  particular  im¬ 
plementations  ,  it  simply  does  not  exist  from  the  point  of 
view  of  specification,  i.e.,  on  the  highest  level  of  general¬ 
ity.  Functions  are  things  that  do,  as  opposed  to  be. 

Sorting  out  different  kinds  of  functions  is  something  we  can 
do  at  lower  levels  of  generality,  but  has  no  place  as  a  re¬ 
quirement  of  the  theory  itself. 

To  illustrate  this  point  again,  suppose  we  have  a  register 
whose  positions  are  filled  with  integers ,  as  in  the  example 
of  Figure  6  (a  stack  or  queue  would  do  just  as  well  for  our 
purposes;  c.f.  Figure  8  for  data  type  stack  and  [Cus77k$  for 
data  type  priority  queue,  for  example) .  Obviously,  there 
is  a  big  difference  between  an  implemented  register  and  the 
integers  it  contains,  and  thus  between  changing  the  state  of 
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the  register  and  taking  one  of  those  integers  as  a  value. 

From  the  point  of  view  of  specification,  however,  a  register 
is  every  bit  as  much  of  an  abstraction  as  an  integer.  The 
two  abstractions  differ,  moreover,  only  in  the  interactive 
behavior  of  the  primitive  operations  that  are  used  to  char¬ 
acterize  their  data  types,  as  this  behavior  is  specified  in 
the  axioms  of  the  respective  type .  From  the  point  of  view  of 
specification,  therefore,  changing  the  state  of  an  implemented 
register  amounts  simply  to  producing  a  new  abstract  register 
as  a  value.  If  we  take  a  register  and  remove  its  last  element, 
for  example,  we  get  a  new  register  that  is  identical  to  the 
original  register  except  that  it  lacks  the  original  register's 
last  element.  This  may  not  be  what  happens  in  implementation , 
but  it  is  the  logic  of  the  situation,  and  that  is  what  speci¬ 
fication  is  really  all  about**. 

As  we  observed  earlier,  Robinson  supplements  his  "abstract 
machines"  with  "abstract  programs"  in  order  to  do  fully  the 
two  jobs  that  Parnas  wants  his  modules  to  do.  Robinson's 
"abstract  programs"  tell  us  what  the  functions  really  are  that 
are  intended  to  be  characterized  in  the  modules. 

Robinson's  intention  can  be  successfully  achieved  by  replacing 
each  component  of  his  framework  with  a  corresponding  component 
of  HOS.  Since  his  "abstract  programs"  serve  as  the  characteri¬ 
zations  of  functions,  we  replace  each  of  them  with  a  decomposi¬ 
tion  tree.  This  relieves  his  "abstract  machine"  modules 
of  the  burden  of  serving  as  the  units  of  system  decomposition 
and  leaves  them  free  to  serve  as  definitions  of  kinds  of  ob¬ 
jects,  which  is  what  they  would  prefer  to  do  anyway,  as  we 
have  seen.  We  thus  replace  each  of  the  "abstract  machines" 
with  a  set  of  data-type  specifications  of  HOS. 

^Note  that  this  is  just  another  way  of  looking  at  what  we  said 
about  queues  in  the  second  paragraph  of  this  section. 
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Formally,  then,  we  replace'  each  of  Robinson's  ordered  (P,M) 
pairs  with  an  ordered  pair  (D,T),  where  D  is  a  set  of  data 
types  replacing  the  "abstract  machine"  M  and  T  is  a  set  of  de¬ 
composition  trees  replacing  the  set  of  "abstract  programs"  P. 
Robinson's  levels  of  abstraction  gets  replaced  with  a  data  level 
of  HOS.  For  simplicity,  we  will  assume  that  the  data  levels 
are  linearly  ordered,  in  order  to  preserve  the  analogy  that 
we  are  developing  with  Robinson" s  account  of  the  SRI  method¬ 
ology,  but,  in  fact,  only  a  partial  ordering  is  really  neces¬ 
sary,  as  long  as  there  is  a  maximal  data  level  in  the  ordering 
that  contains  only  one  tree. 

Higher  data  levels  are  related  to  lower  data  levels  in  that 
the  composition  trees  of  each  data  level  decompose  the 
primitive  operations  of  the  next  higher  data  level  in  terms 
of  the  primitive  operations  of  the  lower  data  level7.  For  every 
primitive  operation  f  of  a  member  of  Di  +  1  Ci^D),  in  other  words, 
there  will  be  a  decomposition  tree  in  whose  root  is  f  and 
whose  leaf  nodes  are  primitive  operations  of  a  member  of  . 

The  primitive  operations  of  the  lowest-data  level  data  types  DQ 
are  the  primitive  operations  of  the  system,  because  these  are 
not  decomposed  at  all,  but  are  characterized  only  in  terms 
of  their  axiomatic  interaction.  The  thus  play  the  role 
of  Robinson's  M.  and  the  T.  play  the  role  of  his  P.,  as  we 
said  we  want  them  to  do,  but  avoiding  any  suggestion  of 
implementation . 

The  simplest  case,  in  which  each  contains  a  single  data  type 
and  in  which  Tn  contains  only  one  decomposed  function  f,  corres¬ 
ponding  to  Robinson's  single  program  P,  is  illustrated  in 
Figure  14  which  clearly  reveals  the  parallel  between  the  HOS 


^We  are  restricting  our  discussion  of  HOS  here  somewhat,  in 
order  to  maintain  as  close  an  analogy  as  possible  with  Robinson's 
framework.  Later  we  will  expand  our  account  by  discussing  HOS 
in  fuller  generality. 
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framework  we  have  developed  here  and  the  SRI  framework  illus¬ 
trated  in  Figure  5-.  The  direction  of  the  arrows  in  Figure  14 
denotes  flow  of  decomposition,  however,  rather  than  flow  of 
implementation,  as  is  the  case  in  Figure  5.  Everything  in 
Figure  14  is  strictly  in  the  realm  of  specification  and  every 
subspecif i -at ion  ("module"),  i.e.,  data  types,  trees,  and 
data  levels,  is  genuinely  self-contained. 

It  is  worth  noticing  at  this  point  that  Figure  14  suggests 
a  way  in  which  a  relatively  simple  proof-of-correctness  pro¬ 
cedure  might  be  developed  for  software  specified  in  HC5 . 
Robinson  gives  the  following  general  account  of  how  a  proof- 
of-correctness  procedure  is  supposed  to  work: 


The  goal  is  to  prove  the  correctness  of  a  program.  P 
with  respect  to  an  input  assertion,  <j> ,  and  an  out¬ 
put  assertion,  t(/.  Verification  requires  the  inser¬ 
tion  of  inductive  assertions  {c[^  }into  the  program's 

flowchart,  breaking  the  program  into  simple  paths. 

Each  simple  path  has  one  entry  and  one  exit  and 
between  these  a  fixed  number  of  executable  statements. 
For  each  simple  path,  a  formula  called  a  verif ication 
condition  (VC)  must  be  stated  and  proved  to  be  a 
theorem.  The  validity  of  all  the  VCs  for  a  program 
is  sufficient  to  demonstrate  the  partial  correctness 
of  a  program — i.e.  for  all  inputs  satisfying  the  input 
assertion,  the  output  assertion  is  satisfied  if  the 
program  terminates.  Termination  can  be  proved  by  ■ 
inductive  assertions  (usually  different  from  those 
used  to  prove  partial  correctness)  that  bound  the 
number  of  loop  executions...  (p.  274). 


If  we  view  Robinson's  description  in  terms  of  Figure  14, 
we  get  the  following  general  picture.  What  we  need  ir.  proof- 
of-correctness  is  a  set  of  intermediate  points  in  the  speci¬ 
fication  of  a  function,  at  which  correctness  assertions  (verifi¬ 
cation  conditions)  are  stated  and  can  be  proven.  In  Figure  14, 
such  intermediate  points  appear  to  be  provided  automatical ly 
at  each  data  level,  where  the  axioms  on  data  types  car.  be  viewed 
as  assertions  on  the  decompositions  of  higher-data  level  primitive 
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operations  into  lower-data  level  primitive  operations.  The 
input  assertions  i  are  provided  by  a  statement  of  what,  in 
general,  we  intended  the  specified  function  no  do.  Spelling 
out  this  procedure  in  detail  will  require  further  work,  but 
the  general  idea  would  seem  to  be  clear. 


SO 
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5 .  HIGHER  ORDER  SOFTWARE  IS  SECURE  SOFTWARE 

Now  we  are  in  a  position  to  return  to  our  main  topic  of  security. 
Given  the  parallels  that  we  have  developed  between  the  SRI 
"specification"  methodology  and  HOS ,  it  would  undoubtedly  be 
useful  to  examine  the  SRI  security  model  in  view  of  these 
parallels  and  see  whether  we  can  shed  any  light  on  how  that 
model  can  be  tightened  up,  as  we  did  for  Walter's.  There  is 
good  reason  for  not  doing  this,  however.  The  SRI  notion  of 
security  is  very  similar  to  Walter's,  as  we  can  see  from  L.he 
following  description  of  that  notion  by  Feiertag: 


♦ 


In  a  multilevel  secure  system  there  is  a  predefined 
set  of  security  levels.  The  security  levels  are  com¬ 
posed  of  clearances  (or  classifications)  and  category 
sets,  but  the  composition  of  tne  security  levels  is 
an  unimportant  detail  for  purposes  of  this  discussion 
and  will  be  largely  ignored8  .  What  is  important  is 
that  the  security  levels  are  partially  ordered  by  the 
relation  "less  than"  represented  by  "<".  Each  pro¬ 
cess  in  a  multilevel  secure  system  is  assigned  a 
security  level.  The  processes  may  invoke  functions 
that  change  the  state  of  the  system  and  return  values. 
Each  function  instantiation  (i.e.,  a  function  with  a 
particular  set  of  argument  values)  is  assigned  a 
security  level.  A  process  may  only  invoke  those 
instantiations  of  functions  that  have  been  assigned 
the  security  level  of  the  process.  A  system  is 
multilevel  secure  if  and  only  if  the  behavior  of  a 
process  at  some  given  security  level  can  be  affected 
only  by  processes  at  a  security  level  less  than  or 
equal  to  the  given  level.  Stated  in  terms  of  func¬ 
tions,  this  says  that  the  values  .returned  by  a 
function  instantiation  assigned  some  security  level 
can  be  affected  only  by  the  invocation  of  function 
instantiations  at  lower  or  equal  security  levels. 

Stated  in  loose  terms  this  means  that  information 
can  flow  only  upward  in  the  system  from  processes 
of  lower  security  level  to  processes  of  higher  security 
level.  [Fei76,  p.  1]. 


We  already  have  enough  at  our  disposal,  however,  to  solve  the 
security  problem  altogether,  without  trying  to  reexamine 
Feiertag 's  model  in  light  of  HOS.  Doing  the  latter  can  thus 
be  left  simply  as  an  interesting  exercise  for  the  reader. 


8l.ike  Feiertag,  Walter  also  informal 
consisting  of  a  "sensitivity  level" 
Feiertag,  this  distinction  plays  no 
Note  that  here,  too,  a  secure  model 
mat  ion  can  flow  only  upward. 


v  character i ces  a  "classification"  as 
and  a  "compartment ,"  but,  also  like 
real  role  in  his  formal  security  model. 
;  v.  character  i  zed  as  one  in  ..hie:’,  infor- 
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We  arrived  at  our  HOS  model  in  Figure  14  by  sticking  fairly 
closely  to  Robinson's  SRI  model,  as  illustrated  in  Figure  5, 
and  showing  that  each  component  of  his  model  could  be  made 
completely  free  of  implementation  by  replacing  it  with  the 
corresponding  HOS  notion.  What  we  found,  essentially,  was 
that  the  step  from  implementation  to  specification  can  indeed 
be  made  in  somewhat  the  way  Robinson  wants,  but  only  if  we 
reformulate  his  notions  in  non- implementation  terms.  To 
capture  successfully  what  Robinson  is  trying  to  express, 
we  have  to  replace  his  "abstract  machines"  with  HOS  data-type 
specifications  and  his  "abstract  programs"  with  HOS  function- 
decomposition  trees. 

In  fact,  however,  HOS  is  considerably  more  general  than  the 
model  in  Figure  14.  In  particular,  there  is  no  reason  for  the 
relationship  between  the  primitive  operations  of  successive 
data  levels  to  be  related  as  directly  as  Figure  14  suggests. 

In  the  figure,  the  primitive  operations  of  one  data  level  are 
decomposed  directly  into  the  primitive  operations  of  the  next 
lower  data  level.  In  general,  however,  there  can  be  inter¬ 
mediate  operations  on  the  lower  data  level  that  mediate  this 
decomposition. 

As  we  noted  earlier,  a  data  level  of  HOS  is  an  ordered  pair 
(D,T) ,  where  D  is  a  set  of  abstract  data  types  and  T  is  a  set 
of  decomposition  trees.  We  also  said  the  data  levels  are 
linearly  (or  partially)  ordered  and  that  they  are  related  in  that 
the  decomposition  trees  of  each  data  level  decompose  the 
primitive  operations  of  the  next  higher  data  level  in  terms  of 
the  primitive  operations  of  the  lower  data  level.  In  the  most 
general  case,  however,  the  decomposition  trees  on  one  data 
level  also  use  the  primitive  operations  of  that  data  level  at 
their  terminal  nodes  to  define  operations  that  do  not  appear 
as  primitive  operations  of  the  next  higher  data  level.  In 
this  case,  there  will  be  further  decomposition  trees  between 
the  data  levels  whose  roots  are  primitive  operations  of  higher 
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data  levels  and  whose  leaves  are  primitive  or  non-primitive 
operations  of  next-lower  data  levels. 

To  put  the  point  a  little  differently,  a  data  level  of  HOS , 
from  the  most  abstract  point  of  view,  is  nothing  more  than 
an  ordered  pair  (D,T) ,  where  D  is  a  collection  of  sets  and 
T  is  a  collection  of  mappings  (mathematical  functions) . 

What  makes  such  an  ordered  pair  an  HOS  data  level,  is  the  kinds 
of  constraints  that  are  imposed  on  D  and  T  by  the  HOS  axioms 
(and  their  consequences) .  Every  member  of  D  is  not  only  a 
set,  but  a  set  whose  members  behave  towards  each  other  in  a 
way  specified  in  an  HOS  data-type  specif ication.  Every  mem¬ 
ber  of  T  is  not'  only  a  mapping,  but  a  mapping  that  is  decom¬ 
posed  in  a  well-formed  HOS  tree. 

The  mappings  in  T  can  represent  completely  general  functions 
and  do  not  have  to  be  primitive  operations  on  either  their 
own  or  any  other  data  level.  If  a  mapping  f  is  non-primitive 
on  its  own  data  level,  then  there  is  a  decomposition  tree  that 
connects  it  to  the  primitive  operations  of  that  data  level. 

Such  a  tree  can  be  said  to  be  horizontal ,  because  it  relates 
primitive  and  non-primitive  operations  on  a  single  data  level. 
There  is  also,  however,  a  vertical  tree  that  relates  f  to  the 
primitive  operations  of  the  next  higher  data  level.  In  this 
tree  f  is  one  of  the  leaves  and  the  root  is  one  of  the  primi¬ 
tive  operations  of  the  higher  data  level. 

What  we  get  instead  of  the  arrows  in  Figure  14,  in  other  words, 
is  a  retroflex  step  structure  like  the  one  in  Figure  15. 

Each  line  segment  in  Figure  15  represents  a  set  of  decomposi¬ 
tion  trees,  some  of  which  are  horizontal  (on  a  data  level) 
and  some  of  which  are  vertical  (between  two  data  levels) . 

The  arrows  point  away  from  the  root  nodes  and  toward  the  leaf 
nodes  of  the  trees  they  represent.  Filled  circles  represent 
primitive  operations  of  a  data  level,  while  filled  squares 
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denote  non-primitive  operations  of  a  data  level.  Movement 
away  from  f  produces  increasingly  decomposed  operations  (func¬ 
tions,  mappings,  §tc.),  i.e.,  an  increasing  degree  of  primi- 
tivity  of  the  operations/functions  involved.  Movement  towards 
f  produces  increasingly  abstract  or  complex  (decomposable) 
operations/functions,  culminating  in  f  itself. 

In  Figure  16  ,  we  elaborate  this  structure  somewhat  for  a  sys¬ 
tem  with  three  data  levels.  As  in  Figure  15,  filled  circles 
in  Figure  11  denote  the  primitive  operations  of  a  data  level, 
while  filled  squares  denote  non-primitive  operations  of  a 
data  level.  Open  circles  denote  non-primitive  operations  that 

9 

are  needed  m  the  intermediate  levels  of  a  decomposition  tree  . 
These  are  described  in  terms  of  the  three  primitive  control 
structures  of  HOS  (composition,  set  partition,  and  class  parti¬ 
tion,  as  illustrated  in  Figure  13)  or  in  terms  of  abstract 
control  structures  that  are  definable  in  terms  of  the  three 
primitive  control  structures,  as  we  mentioned  in  Section  4. 

Trees  with  solid  branches  are  horizontal  trees,  which  decom¬ 
pose  non-primitive  operations  of  a  data  level  in  terms  of 
primitive  operations  of  the  same  data  level.  Trees  with 
dashed  branches  are  vertical  trees  which  decompose  primitive 
operations  of  a  data  level  in  terms  of  non-primitive  opera¬ 
tions  of  the  next  lower  data  level.  Note  that  primitivity  of 
operations  is  a  relative  notion, defined  with  respect  to  the 
data  level  an  operation  is  defined  on. 

New  we  are  ready  to  solve  the  security  problem.  Clearly,  if 

we  are  not  interested,  for  some  reason,  in  the  data-level 

structure  of  a  particular  f  that  has  been  decomposed  as  in 

Figures  15  and  16  ,  then  we  can  "fix"  f  in  space,  as  it  were, 

and  "pull  the  rug  out"  from  under  the  lowest  data  level,  so 

that  the  filled  nodes  in  the  diagram  act  as  pivots  and  the 

entire  system  stretches  out  into  one  gigantic  tree  structure, 

as  in  Figure  17.  In  conjunction  with  the  HOS  axioms,  however, 

-  - 

Note  that  HOS  levels  are  defined  relative  to  a  controller, 

or  parent  module,  whereas  Robinson's  are  not.  See  [ Ham76a , b , c ] . 
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this  fact  automatically  provides  us  with  the  solution  to  the 
security  problem. 

Consider  Axioms  3  and  4,  in  particular  (Figure  12)  •  These  are 
the  axioms  that  specify  the  access  rights  ir.  an  HOS  system  and 
would  thus  be  expected  to  have  something  to  do  with  security. 
Axiom  3  states  that  the  access  rights  tc  the  output  of  a  func¬ 
tion  in  a  tree  like  that  of  Figure  17  are  controlled  by,  and 
only  by,  its  parent  node  ("module",  in  the  axiom)  ,  i.e.,  the 
node  immediately  above  it.  Axiom  4,  similarly,  states  that  the 
access  rights  to  the  input  of  a  function  in  such  a  tree  is 
also  controlled  by  and  only  by,  its  parent  node.  A  given  func¬ 
tion  can  look  at  data  only  if  its  parent  allows  it  to,  and 
it  must  dispose  of  its  results,  again,  only  as  its  parent  allows 
it  to.  It  follows  that  the  flow  of  control  in  an  HOS  system 
is  always  from  the  top  down. 

The  flow  of  information,  however,  is  always  from  the  bottom  up. 

A  given  node  performs  its  function  by  having  its  offspring 
nodes,  i.e.,  those  on  the  immediately  lower  level,  perform 
the  function  for  it.  This,  in  fact,  is  precisely  what  de¬ 
composition  is  really  all  about.  Decomposing  a  function  is 
just  a  formalized  version  of  delegating  responsibility. 

If  someone  can  perform  a  task  all  by  himself,  then  there  is 
no  point  in  delegating  that  task  to  subordinates.  If_  respon¬ 
sibility  is  delegated,  then  he  performs  his  task  precisely  by 
guaranteeing  (via  control)  that  his  subordinates  perform  theirs. 
Formally,  the  offspring  nodes  look  at  the  data  that  the  parent 
allows  them  to  (Axiom  4) ,  perform  their  functions  on  that  data 
as  input,  and  then  dispose  of  that  data  as  the  parent  requires 
(Axiom  3),  i.e.,  either  by  reporting  it  directly  to  the  parent 
or  by  passing  it  on  to  an  appropriate  sibling.  In  particular, 
a  given  function  has  no  idea  what  higher-level  functions  are 
doing.  It  just  chugs  along,  turning  input  into  output,  dis¬ 
posing  of  that  output  as  its  parent  tells  it  to.  It  i£  aware 
of  what  its  offspring  (or  perhaps,  siblings)  are  doing,  however, 
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because  that  is  precisely  where  it  gets  its  input  from  in 
the  firs;,  place. 


The  distinction  between  variables  and  values  becomes  very  im¬ 
portant  here.  Control  is  defined  in  terms  of  variables ,  but 
information  is  defined  in  terms  of  values .  A  node  controls 
the  access  rights  of  its  offspring  to  variables .  The  node 
tells  the  offspring  what  variables  they  can  look  at  and  what 
variables  they  must  report  back  about.  The  offspring  thus 
get  their  variables  from  the  parent.  This  is  the  sense  in 
which  control  flows  downward .  The  parent  node  has  no  idea 
what  the  values  of  those  variables  are,  however,  until  it  gets 
those  values  from  its  offspring.  The  parent  tells  an  offspring 
what  variable  to  look  at;  then  the  offspring  looks  at  the  vari¬ 
able  to  find  its  value,  operates  on  that  value  as  input  to 
change  it  into  a  value  of  an  output  variable,  and  then  reports 
that  value  (either  to  a  sibling  or)  back  to  the  parent.  Thus, 
while  parents  tell  offspring  what  variables  they  can  look  at 
and  assign,  it  is  the  offspring  that  tell  the  parents  what  the 
values  of  those  variables  are.  It  follows  that  information 
can  flow  only  upward ,  precisely,  in  fact,  because  control 
flows  downward,  as  stated  in  Axioms  3  and  4. 

Our  proof  that  information  flows  only  upward  in  an  HOS  system 
required  us  to  use  the  de-retrof lexed  tree  in  Figure  17 ,  be¬ 
cause  the  HOS  axioms  are  stated  in  terms  of  trees  (control 
maps),  not  in  terms  of  retroflex  trees,  like  the  data-leveled 
structure  in  Figure  16.  Since  Figure  11  is  functionally  equiva¬ 
lent,  however,  to  Figure  17,  differing,  in  fact,  only  in  its 
arrangement  on  the  page,  our  proof  of  upward  information  flow 
is  also  valid  for  Figure  16. 

The  significance  of  this  result  cannot  be  overemphasized. 

As  we  saw  in  connection  with  Walter's  Mq ,  a  secure  system  is 
one  in  which  the  repositories  (data)  and  agents  (functions) 
are  ordered  in  such  a  way,  and  the  access  rights  of  the  agents 
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(functions)  to  the  repositories  (data)  are  assigned  in  such  a 
way,  that  information  can  flow  only  upward  in  the  ordering.  What 
we  have  shown  here,  however,  is  that,  if  a  system  is  specified 
in  accordance  with  HOS,  then  its  functions  (agents)  and  data 
(repositories)  are  so  ordered,  and  the  access  rights  of  the  func¬ 
tions  (agents)  to  the  data  (repositories)  are  so  assigned,  that 
information  does  always  flow  upward  in  the  ordering.  In  other 
words,  systems  specified  in  HOS  are  automatically  secure ,  without 
the  need  for  any  further  paraphernalia  to  guarantee  the  security 
for  us. 

It  follows  that  we  have  completely  solved  the  security  problem. 

If  software  is  specified  in  HOS,  then  it  is  secure.  It  is 
that  simple.  Our  proof  of  this  fact  also  enables  us  to  re¬ 
fine  our  discussion  of  HOS  somewhat,  and  it  would  be  worth 
while  to  pursue  this  opportunity  a  bit.  We  saw  earlier  that 
systems  have  a  dual  character  in  two  distinct  senses.  On 
the  one  hand,  a  system  is  a  function,  since  it  performs  a 
function,  and  it  is  also  a  datum  in  that  it  exists  at  all. 

On  the  other  hand,  a  system  consists  of  both  data  and  func¬ 
tions  and  these  two  components  are  inseparable.  What  our 
proof  of  security  makes  clear,  furthermore,  is  that  each  of 
these  components  has  a  dual  character  as  well,  and  again, 
in  two  senses,  when  actually  put  together  into  a  system. 


A  function  in  a  system  decomposition  is  a  controller ,  because 
it  controls  the  behavior  of  its  offspring,  in  accordance  with 
the  axioms  of  HOS.  It  is  also  a  performer ,  however,  because 
it  carries  out  the  mapping  of  its  parent.  Every  function 
plays  both  roles  and  the  very  fact  that  it  plays  one  is  the 
reason  it  must  also  play  the  other^  Data  types  also  serve 
in  two  capacities  in  system  decompositions.  Every  data  type 
involved  in  a  system  decomposition  provides  both  the  input 
of  one  function  and  the  output  of  another.  "In"  and  "out" 
are  as  diametrically  opposed  as  any  two  things  can  be,  but, 


Primitive  operations  are  also  controllers  (potentially),  because  we  can 
always  add  a  lower  data  level  in  which  they  are  decomposed.  Similarly, 
the  highest- level  function  in  a  system  is  also  a  performer  (potentially), 
because  we  can  always  use  a  system  as  a  subsystem  of  some  other  system. 
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again,  we  cannot  have  one  without  the  other. 

Our  components  are  also  dual-natured  in  a  second  way.  On 
the  one  hand,  data  have  a  constant  aspect,  as  individual  ob¬ 
jects  that  can  serve  as  inputs  or  outputs  of  functions,  but, 
on  the  other  hand,  they  have  a  variable  aspect,  because  they 
exist  as  the  members  of  data  types.  A  given  datum  is  an  in¬ 
dividual  object  itself,  but  it  is  also  a  representative  mem¬ 
ber  of  a  data  type  that  can  serve  as  a  value  of  a  variable 
of  that  type.  This  dichotomy  enables  functions  to  play  a 
dual  role  in  systems  in  a  second  sense  as  well .  In  Walter's 
terminology,  a  function  can  observe  functions  at  a  lower  level 
of  its  decomposition  tree  by  receiving  data  values  from  output 
variables  of  those  functions  and  can  modify  functions  at  a 
higher  level  of  its  decomposition  tree  by  providing  data  values 
to  input  variables  of  those  functions. 

On  the  one  hand,  therefore,  functions  act  as  agents ,  since 
they  can  observe  lower-level  functions  and  modify  higher- 
level  functions.  What  really  gets  observed  and  modified  by 
these  agents  are  the  output  variables  of  the  respective  func¬ 
tions  with  the  modification  occurring  via  the  use  of  the  input 
variables,  so  it  is  the  output  variables  that  serve  as  the 
repositories  of  the  system.  On  the  other  hand,  the  input 
variables  also  function  as  agents  because  it  is  they  that 
give  the  relevant  values  to  their  functions  to  use  in  modify¬ 
ing  the  values  of  the  output  variables.  In  general,  in  other 
words,  it  is  the  complete  functions  themselves — mappings,  do¬ 
mains,  and  ranges,  with  the  latter  two  represented  by  variables — 
that  act  both  as  agents  and  repositories  in  an  HOS  system. 

It  follows  that  we  not  only  do  not  have  to  distinguish  between 
repositories  and  security  classes,  as  we  saw  earlier,  but  we 
do  not  really  even  have  to  distinguish  between  repositories 
and  agents  either.  Since  a  function  all  by  itself  already 
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has  a  dual  character,  being  made  up  of  a  napping  and  two  data 
types,  functions  themselves  can  play  both  roles.  When  func¬ 
tions  occur  in  a  tree,  they  can  observe  and  modify  other  func¬ 
tions  and  they  can  also  be  observed  and  modified  b^  other  func¬ 
tions.  Since  they  occur  in  a  tree  structure  in  any  system, 
the  functions  themselves,  and  therefore  the  "agents"  and  "re¬ 
positories,"  which  the  functions,  are,  are  partially  ordered, 

(and  thus  also  pre-ordered) ,  just  as  Walter  wants  them  to  be. 

A  function  in  a  system  i_s  both  an  agent  and  a  repository 
and,  since  it  occurs  in  a  tree  structure,  can  also  serve  as 
its  own  security  class.  This  is  about  as  cozy  an  arrangement 
as  we  could  possibly  want  and,  as  we  have  seen  quite  clearly, 
it  is  absolutely  secure. 
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SOFTWARE ,  SYSTEMS,  SEMANTICS,  AND  BEYOND... 


In  most  real  scientific  breakthroughs,  the  applicability, 
usefulness,  and  explanatory  power  of  a  new  theory  goes  well 
beyond  the  restricted  kind  of  problem  it  was  originally 
intended  to  solve.  All  such  developments  clearly  exhibit 
the  contradictory  aspects  of  similarity  and  difference,  of 
continuity  and  change.  Major  breakthroughs  always  bear 
strong  similarities  to  existing  theories,  but  differ  from 
them  in  key  respects  whose  logical  implications  turn  cut  to 
make  all  the  difference. 

These  sorts  of  -characteristic  are  clearly  evident  in  the  case 
of  HOS  as  an  approach  to  systems  theory.  We  have  seer,  that, 
while  HOS  was  originally  developed  for  the  specification  of 
reliable  software,  it  turns  out  to  provide  automatically 
the  solution  to  the  security  problem  as  well.  Many  HOS  concepts 
look  very  much  like  the  notions  contained  in  other  theories. 
Very  close  examination  reveals,  however,  that  HOS  differs 
from  other  formulations  in  precisely  the  ways  that  are  re¬ 
quired  by  the  problem  the  theories  are  trying  to  solve. 

What  results  is  a  completely  adequate  methodology,  for  the 
specification  of  software  systems  that  are  reliable  and 
secure. 

In  fact,  what  results  is  much  more  than  that.  HOS  seems 
capable  of  providing  insight  into  problems  that  are  well 
beyond  its  intended  field  of  software  engineering.  There 
is  nothing  in  HOS,  in  other  words,  that  requires  us  to 
restrict  its  use  to  specifying  software  systems.  As  a 
general  systems  theory,  HOS  can  be  fruitfully  applied  in  any 
field  in  which  systems  can  be  seen  to  be  playing  a  role. 

George  Miller  has  suggested  to  us  (personal  communication) 
that  HOS  control  hierarchies  might  be  useful  in  accounting 
for  the  behavior  induced  by  operant  conditioning,  and  we 
have  ourselves  been  investigating  its  usefulness  as  a  tool 
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in  analyzing  natural  language.  The  HOS  distinction  between 
data  and  functions,  for  example,  can  be  interpreted  as  pro¬ 
viding  a  semantic  model ,  in  the  sense  of  Wilson  [Wil76] , 

[Mill76] .  Wilson's  own  semantic  model,  illustrated  in  Figure  18, 
is  considerably  less  general,  recognizing  seven  modes  of  exist¬ 
ence,  which  he  calls  "concept  types":  objects,  properties, 
relationships,  events,  actions,  procedures,  and  sets.  Such 
a  model  would  certainly  be  useful  for  many  purposes,  but  its 
limited  generality  cannot  help  but  conceal  significant  generali¬ 
zations  that  might  help  to  simplify  specific  system  specifi¬ 
cations  and  suggest  alternate  implementations.  Wilson's 
model  represents  a  number  of  possible  implementations  of 
the  HOS  model  at  a  lower  level  of  generality.  His  "object 
classes,"  "property  classes,"  "relations/attributes,"  and 
"sets,"  for  example,  could  represent  a  particular  selection 
of  data  types,  with  "events,"  "actions,"  and  "procedures" 
corresponding  to  different  classes  of  functions.  The  former, 
after  all,  represent  things  that  are  (be),  while  the  latter 
represent  things  that  do. 

The  data/function  dichotomy  could  be  distributed  among  Wilson's 
seven  "concept  types"  in  other  ways  as  well,  but  the  question 
that  immediately  strikes  one  on  first  coming  across  his  model 
is  that  of  why  he  chooses  these  seven  in  the  first  place.  The 
problem  with  Wilson's  semantic  model,  in  other  words,  as  a  general 
systems  (or  semantic)  theory,  is  that  it  is  essentially  ad  hoc 
and,  therefore,  of  limited  generality.  Actions  certainly 
constitute  events ,  for  example,  so  they  could  be  subsumed 
under  them.  Reversing  direction,  we  could  elaborate  actions 
further,  distinguishing  them  into  transitive  and  intransitive 
actions,  perhaps.  Properties,  similarly,  could  be  taken  to 
be  one-place  relationships,  as  they  often  are.  The  point  is 
that  Wilson's  theory  provides  no  natural  mechanism  with  which 
to  make  the  plethora  of  such  decisions  that  might  arise  in 
specific  cases  of  system  design.  The  number  of  "concept 
types"  is  stipulated  to  be  seven,  ir.  the  theory  itself,  and 
that  is  that.  HOS,  in  contrast,  distinguishes  only  between 
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CONCEPT  TYPES 


Instances 

Classes  (Abstracted  from  Instances) 

obj  ects 

object  classes 

properties 

property  classes 

relat ionships 

relations/attributes 

events 

event  classes 

actions 

action  classes 

procedures 

procedure  classes 

sets 

set  classes 

CERTAIN  KEV  RELATIONSHIPS  BETWEEN  CONCEPTS 

INSTANCE  of/CLASS  of 

SUBCLASS  of/SUPERCLASS  of 

COMPONENT  of  SUPERCOMPOSITE  of  (PART /WHOLE) 

MEMBER  of/SET  MEMBERSHIP  of 

SUBSET  of/SUPERSET  of 


Figure  18.  Wilson's  Semantic  Model  [  V,'  1 1 7  €  ,  p.  7] 
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data  and  functions,  while  permitting  any  instance  of  either 
to  be  also  an  instance  of  the  other.  Given  this  generality, 
we  can  begin  restricting  things  anyway  we  like  for  any  parti¬ 
cular  problem:  three  special  data  types  and  four  classes  of 
functions,  two  special  data  types  and  six  classes  of  func¬ 
tions,  ten  special  data  types  and  one  class  of  functions,  etc. 
Once  we  let  ourselves  get  more  concrete  than  simply  being 
versus  doing ,  in  other  words,  there  is  r.o  clear  general 
criterion  for  what  our  categories,  modes  of  existence,  or 
concept  types  should  be,  because  each  application  or  class 
of  applications  will  favor  a  different  choice.  An  adequate 
general  systems  theory  must  be  formulated  at  the  highest  level 
of  generality,  so  that  no  possibly  desired  choice  of  imple¬ 
mentation  will  be  ruled  out,  or  made  intrinsically  more  dif¬ 
ficult,  ahead  of  time. 

By  distinguishing  only  between  data  types  and  functions,  in 
other  words,  HOS  lets  each  particular  more  or  less  concrete 
application  select  exactly  the  specific  data  types  and  func¬ 
tions  it  needs,  rather  than  arbitrarily  stopping  the  theory 
short  at  a  lower  level  of  generality,  and  possibly  ruling 
out  the  optimal  choice  of  data  types  and  functions  for  a 
particular  application.  The  point  here  is  not  that  Wilson's 
semantic  model  is  wrong ,  but  that,  unlike  HOS,  it  is  not 
fully  general ,  and,  therefore,  not  fully  adequate. 

One  final  point  remains  to  be  made  before  we  close.  The 
reasqn  that  system  specification  has  been  such  a  difficult 
thing  to  figure  out  is  that,  as  we  have  seen,  a  system  is  an 
intrinsically  contradictory  object.  On  the  one  hand,  a 
system  is  a  single  object;  on  the  other  hand,  it  is  made  up 
of  many  different  objects.  On  the  one  hand,  a  system  performs 
a  function  on  objects;  on  the  other  hand,  it  i_s  an  object  on 
which  functions  can  be  performed.  On  the  one  hand,  a  system 
consists  of  two  distinct  kinds  of  objects,  functions  and  data; 
on  the  other  hand,  functions  can  be  data  and  data  can  be 
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functions,  so  only  one  sort  of  thing  is  really  involved. 

A  datum  can  be  an  input  to-  a  function,  but  it  can  be  so  only 
by  being  an  output-  to  a  function,  and  vice  versa.  A  function 
controls  other  functions,  but  it  also  gets  controlled  by 
another  function.  A  datum  is  an  individual  object,  with  a 
constant  aspect,  and  also  a  representative  of  a  data  type,  with 
a  variable  aspect.  Functions  are  defined  in  terms  of  vari¬ 
ables  ,  i.e. ,  representatives  of  data  types,  but  operate  on 
constants ,  i.e.,  individual  data,  and  so  on. 

Given  all  these  twists  and  turns  on  the  road  to  specification, 
it  is  not  surprising  that  so  many  have  lost  their  way.  The 
uniqueness  and  power  of  HOS  consists  precisely  in  the  fact 
that  it  manages  to  resolve  all  of  these  contradictions  in  one 
fell  swoop  and  makes  them  comprehensible. 
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